Program and information processing device allowing storage of information for identifying user

ABSTRACT

When setting that a situation permits photographing is made, a CPU causes a first image obtained by photographing of a field by an image pick-up portion to be stored as an input image in association with prescribed information. In contrast, when setting that a situation does not permit photographing is made, the CPU accepts user&#39;s drawing input onto an input portion and causes a second image in accordance with the drawing input to be stored as the input image in association with the prescribed information. Thus, an image of a type appropriate for a condition of use can be stored in association with the prescribed information.

This nonprovisional application is based on Japanese Patent ApplicationNo. 2008-310127 filed with the Japan Patent Office on Dec. 4, 2008, theentire contents of which are hereby incorporated by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a program and an information processingdevice allowing storage of information for identifying a user incorrespondence with an image indicating a user.

2. Description of the Background Art

Such a configuration that user information is registered in advance andthe user information is called as necessary has conventionally beenknown.

For example, Japanese Patent Laying-Open No, 2007-080180 discloses aportable terminal having a function as a telephone book defined by aname, a telephone number and a head shot of a user.

In registering the user information in association with the head shot ofthe user as disclosed in the prior art described above, the head shot ofthe user should be obtained using some kind of image pick-up means.Here, in some cases, a head shot of the user cannot be obtained. In sucha case, instead of the head shot, a default image is displayed.Therefore, when a head shot cannot be photographed, an image with whicha user cannot substantially be identified is displayed and a displayarea therefor is wasted.

SUMMARY OF THE INVENTION

The present invention was made to solve the above-described problems. Anobject of the present invention is to provide a program and aninformation processing device with which an image of a type appropriatefor a condition of use can be stored in association with prescribedinformation.

According to one aspect of the present invention, a non-transitorycomputer-readable storage medium with an executable program storedthereon is provided. The present program instructs a computer (100; areference numeral used in embodiments; to be understood similarlyhereinafter) interacting with an image pick-up portion (23) and an inputportion (13) capable of detecting a coordinate on which an inputoperation was performed to perform a storage step (13, 34; S124, S126,S132, S138, S160, S158) of storing an input image in association withprescribed information, and a setting step (13; S100) of making settingas to whether a situation permits photographing by the image pick-upportion or not. The storage step includes the steps of storing a firstimage obtained by photographing of a field by the image pick-up portionas the input image in association with the prescribed information whensetting that the situation permits photographing is made (13, 34; S124,S126, S132, S138), and accepting user's drawing input onto the inputportion and causing a second image in accordance with the drawing inputto be stored as the input image in association with the prescribedinformation when setting that the situation does not permitphotographing is made (13, 34; S160, S158).

According to this first aspect, whether a situation permitsphotographing by the image pick-up portion or not is set, and inaccordance with this setting, prescribed information is stored inassociation with any of the first image obtained by photographing of thefield by the image pick-up portion and the second image input throughuser's drawing input. Therefore, even when a user does not desirephotographing of a face or if the user is at a location wherephotographing is prohibited, a hand-drawn image input by the user canalternatively be stored in association with the prescribed information.Thus, as the prescribed information can be displayed in correspondencewith a unique image indicating the user, an area for displaying theimage can effectively be made use of, and the user associated with theprescribed information can more reliably be specified.

According to a preferred second aspect, the computer further interactswith a display portion (12, 22). The setting step includes the step ofcausing the display portion to display an image inviting the user tomake selection as to whether the situation permits photographing or not.

According to this second aspect, the user can make selection as towhether or not to permit photographing of his/her own face. Therefore,the user can determine which image is to be used based on his/her ownintention.

According to a preferred third aspect, the storage step includes thestep of storing, for each of a plurality of pieces of prescribedinformation, any of the first image and the second image in associationwith each piece of the prescribed information.

According to this third aspect, even when a plurality of pieces ofprescribed information are registered, each piece of prescribedinformation can be displayed in correspondence with any of the firstimage obtained by photographing of the field by the image pick-upportion and the second image input through the user's drawing input.

According to a further preferred fourth aspect, the program furtherinstructs the computer to perform an output step of outputting in a listthe first image or the second image associated with the plurality ofpieces of prescribed information, in correspondence with contents in theassociated prescribed information.

According to this fourth aspect, when a plurality of pieces ofprescribed information are registered, already-registered prescribedinformation can be checked as a whole.

According to another aspect of the present invention, a non-transitorycomputer-readable storage medium with an executable program storedthereon is provided. The present program instructs a computer (100)interacting with an image pick-up portion (23) and an input portion (13)capable of detecting a coordinate on which an input operation wasperformed to perform: a storage step of storing a result of execution ofa prescribed interactive application and an identification image inassociation with each other; an identification information input step ofaccepting, each time the prescribed interactive application is executed,input of the identification image indicating a user who executed theinteractive application; and a setting step of making setting as towhether a situation permits photographing by the image pick-up portionor not. The storage step includes the step of storing a first imageobtained by photographing of a field by the image pick-up portion as theidentification image in association with the result of execution of theinteractive application when setting that the situation permitsphotographing is made, and accepting user's drawing input onto the inputportion and causing a second image in accordance with the drawing inputto be stored as the identification image in association with the resultof execution of the interactive application when setting that thesituation does not permit photographing is made.

According to this aspect, if a situation does not permit photographingby the image pick-up portion, the user is caused to provide drawinginput, so that a second image is substantially forcibly stored. Then, aresult of execution of the interactive application is stored inassociation with this second image. Therefore, whether the situationpermits or does not permit photographing by the image pick-up portion,the result of execution of the interactive application can reliably bestored in association with the user identification information.

According to a preferred sixth aspect, the storage step further includesthe step of storing a third image obtained by photographing of the fieldby the image pick-up portion as the identification image in associationwith prescribed information associated with the second image after thesecond image was stored as an input image in the storage step whensetting that the situation did not permit photographing was made in thesetting step.

According to this aspect, in such case that a situation does not permitphotographing by the image pick-up portion at certain timing butsubsequently the situation changes and photographing by the imagepick-up portion is permitted, the result of execution of the interactiveapplication can be stored in association with the third image obtainedby photographing of the field by the image pick-up portion instead ofthe second image, as in the case of the first image.

According to a yet another aspect of the present invention, aninformation processing device (100) interacting with an image pick-upportion (23) and an input portion (13) capable of detecting a coordinateon which an input operation was performed is provided. The informationprocessing device includes a storage portion (13, 34) for storing aninput image in association with prescribed information, and a settingunit (13; S100) for making setting as to whether a situation permitsphotographing by the image pick-up portion or not. The storage portionis configured to store a first image obtained by photographing of afield by the image pick-up portion as the input image in associationwith the prescribed information when setting that the situation permitsphotographing is made (S124, S126, S132, S138), and accept user'sdrawing input onto the input portion and cause a second image inaccordance with the drawing input to be stored as the input image inassociation with the prescribed information when setting that thesituation does not permit photographing is made (S160, S158).

According to a preferred eighth aspect, the image pick-up portion isarranged to include a face of a user in the field of the image pick-upportion while the user holds the computer.

According to this eighth aspect, a face can be photographed while theuser holds the information processing device. Therefore, it is notnecessary to hold the information processing device in a special statein order to photograph a face.

In the description above, reference numerals for indicatingcorrespondence with embodiments which will be described later,supplemental explanation and the like are provided for betterunderstanding of the present invention, however, they are not intendedto limit the present invention in any manner.

According to the present invention, a program and an informationprocessing device with which an image of a type appropriate for acondition of use can be stored in association with prescribedinformation can be provided.

The foregoing and other objects, features, aspects and advantages of thepresent invention will become more apparent from the following detaileddescription of the present invention when taken in conjunction with theaccompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows appearance of a game device (unfolded state) according toan embodiment of the present invention.

FIG. 2 shows appearance of the game device (folded state) according tothe embodiment of the present invention.

FIG. 3 is a block diagram showing an exemplary internal configuration ofthe game device according to the embodiment of the present invention.

FIG. 4 is a diagram showing a manner of providing a program to the gamedevice according to the embodiment of the present invention.

FIG. 5 is a state transition diagram showing overview of an interactiveapplication according to the embodiment of the present invention.

FIG. 6 is a diagram showing an exemplary title menu (at the time ofstart-up for the first time) according to the embodiment of the presentinvention.

FIGS. 7A and 7B are diagrams showing an exemplary title menu (for thesecond time or later) according to the embodiment of the presentinvention.

FIG. 8 is a diagram showing an exemplary main menu for an owneraccording to the embodiment of the present invention.

FIG. 9 is a diagram showing an exemplary main menu for a guest accordingto the embodiment of the present invention.

FIG. 10 is a diagram showing a file structure used with an applicationaccording to the embodiment of the present invention.

FIG. 11 is a diagram showing a screen display example for checkinghandedness according to the embodiment of the present invention.

FIGS. 12A and 12B are diagrams showing a manner of use of the gamedevice according to the embodiment of the present invention.

FIGS. 13A and 13B are diagrams for illustrating overview of processingfor image pick-up/display with the use of an inner camera according tothe embodiment of the present invention.

FIGS. 14A and 14B are diagrams for illustrating display processingaccording to the embodiment of the present invention.

FIG. 15 is a block diagram for providing image pick-up/displayprocessing in accordance with handedness according to the embodiment ofthe present invention.

FIG. 16 is a flowchart showing a processing procedure of processing forregistering owner identification information according to the embodimentof the present invention.

FIG. 17 is a flowchart showing a processing procedure in a face imageobtaining sub routine according to the embodiment of the presentinvention.

FIG. 18 is a flowchart showing a processing procedure in a signatureimage obtaining sub routine according to the embodiment of the presentinvention.

FIGS. 19 to 27 are diagrams showing screen display examples involvedwith the processing for registering owner identification informationaccording to the embodiment of the present invention.

FIG. 28 is a diagram showing an exemplary menu screen in a training gamein an owner mode according to the embodiment of the present invention.

FIG. 29 is a diagram showing an exemplary menu screen in a training gamein a guest mode according to the embodiment of the present invention.

FIG. 30 is a flowchart showing a processing procedure in the traininggame according to the embodiment of the present invention.

FIGS. 31A and 31B are flowcharts each showing a processing procedure ina check game according to the embodiment of the present invention.

FIGS. 32 to 35 are diagrams showing screen display examples involvedwith the check game according to the embodiment of the presentinvention.

FIGS. 36A and 36B are flowcharts each showing a processing procedure inan association game in an owner mode according to the embodiment of thepresent invention.

FIGS. 37A and 37B are flowcharts each showing a processing procedure inan association game in a guest mode according to the embodiment of thepresent invention.

FIGS. 38 to 43 are diagrams showing screen display examples involvedwith the association game according to the embodiment of the presentinvention.

FIG. 44 is a flowchart showing a procedure for processing acommemorative photo function according to the embodiment of the presentinvention.

FIGS. 45 and 46 are diagrams showing examples of outputs created by thecommemorative photo function according to the embodiment of the presentinvention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

An embodiment of the present invention will be described in detail withreference to the drawings. The same or corresponding elements in thedrawings have the same reference characters allotted, and descriptionthereof will not be repeated.

A portable game device 100 will be described hereinafter as arepresentative example of a computer or an information processing deviceaccording to the present invention. Game device 100 can interact withimage pick-up means (or an image pick-up portion), input means (or aninput portion) capable of detecting a coordinate on which an inputoperation was performed, and display means (or a display portion). Inaddition, a program executed by game device 100 will be described by wayof example of a program according to the present invention. It is notedthat the information processing device according to the presentinvention is not limited to a game device, and it may be implemented asa personal computer capable of executing various applications. Inaddition, the program according to the present invention may beincorporated as a function of some of various applications executed on apersonal computer.

<Definition of Terms>

It is noted here that “to interact with” means that such devices as theimage pick-up means (or the image pick-up portion), the input means (orthe input portion), and the display means (or the display portion) areconnected to the computer through wired or wireless connection to allowcommunication of data. Here, such devices as the image pick-up means (orthe image pick-up portion), the input means (or the input portion), andthe display means (or the display portion) may integrally be formed witha computer or provided separately therefrom.

Regarding a typical example of the input means (or the input portion)capable of detecting a coordinate on which an input operation wasperformed, in a case of a portable device as will be described later, atouch panel is preferably adopted. Alternatively, a mouse, a trackball,a pen tablet, or the like may be employed. Alternatively, a pointer(typically, a controller of Wii® or the like) capable of remotelyindicating a coordinate on a display surface of the display means (suchas a display monitor) may be employed.

Obtaining image data from the image pick-up means (or the image pick-upportion) is herein referred to as “image pick-up”, and storage (saving)of picked-up image data is referred to as “photographing” or“capturing”.

For distinction between an image obtained by the image pick-up means (orthe image pick-up portion) and an image in accordance with a trail of aninput operation through the input means (or the input portion) (drawinginput), these images are herein also referred to as a “camera image” anda “hand-drawn image”, respectively.

An image brought in correspondence with an internal command or aninternal operation and displayed for accepting a correspondinginstruction in accordance with selection (touch operation) through theinput means (or the input portion) is herein also referred to as an“instruction image”. In addition, an image displayed on the displaymeans (or the display portion) for notifying a user of some message isalso referred to as a “notification image”.

<Appearance>

Referring to FIGS. 1 and 2, game device 100 according to the presentembodiment is a foldable-type portable game device. FIG. 1 shows gamedevice 100 in an unfolded state (opened state) and FIG. 2 shows gamedevice 100 in a folded state (closed state). Game device 100 isconfigured to have such a size that a user can hold game device 100 withboth hands or one hand even in the unfolded state.

Game device 100 has a first housing 11 and a second housing 21. Firsthousing 11 and second housing 21 are coupled to allow opening andclosing (be foldable). In the example shown in FIG. 1, first housing 11and second housing 21 are each formed like a rectangular plate, and theyare coupled to each other to be pivotable around a long side portionthereof by means of a hinge.

Normally, the user uses game device 100 in the opened state. On theother hand, game device 100 is closed when the user does not use gamedevice 100. In game device 100, an angle between first housing 11 andsecond housing 21 can also be maintained at a value between a closedposition (substantially 0 degrees) and an opened position (substantially180 degrees) as necessary. Namely, first housing 11 can rest at anyangle with respect to second housing 21. Here, friction force generatedin a coupling portion where first housing 11 and second housing 21 arecoupled to each other can be utilized. In addition to or instead of thefriction force, a latch mechanism may be adopted in the coupling portionwhere first housing 11 and second housing 21 are coupled to each other.

A first LCD (Liquid Crystal Display) 12 is provided as the displayportion (display means) in first housing 11. First LCD 12 has arectangular shape and it is arranged such that a direction in which itslong side extends coincides with a direction in which a long side offirst housing 11 extends. In the present embodiment, though an LCD isemployed as the display portion (display means), other appropriatedisplay devices such as a display device utilizing EL (ElectroLuminescence) may be adopted. In addition, resolution of the displayportion (display means) can be designed as appropriate in accordancewith an application to be executed.

Buttons 14A to 14K for performing various operations on game device 100are provided as the input portion (input means) in first housing 11.Among buttons 14A to 14K, a direction input button 14A, an operationbutton 14B, an operation button 14C, an operation button 14D, anoperation button 14E, a power button 14F, a start button 14G, and aselect button 14H are provided on an inner main surface of first housing11, which is located on the inner side when first housing 11 and secondhousing 21 are folded.

Namely, in exemplary arrangement shown in FIG. 1, direction input button14A and power button 14F are provided on the main surface on one of leftand right sides (left side in FIG. 1) of first LCD 12 provided aroundthe center of the inner main surface of first housing 11. Buttons 14B to14E, start button 14G, and select button 14H are provided on the innermain surface of first housing 11 on the other of left and right sides(right side in FIG. 1) of first LCD 12.

An L button 14I is provided at a left end portion of an upper sidesurface of first housing 11, and an R button 14J is provided at a rightend portion on the upper side surface of first housing 11. In addition,a volume button 14K is provided on a left side surface of first housing11.

Direction input button 14A, L button 14I and R button 14J are used, forexample, for a selection operation. Buttons 14B to 14E are used, forexample, for an enter operation or a cancel operation. Power button 14Fis used for turning on/off the power of game device 100. Volume button14K is used for adjusting a volume of a speaker included in game device100.

Game device 100 further includes a touch panel 13 as the input portion(input means) different from buttons 14A to 14K. Touch panel 13 isattached to cover a screen of first LCD 12 and detects a coordinate whenthe user performs an input operation. Namely, touch panel 13 is arrangedin correspondence with the display surface of first LCD 12.

For example, a resistive touch panel may be employed as touch panel 13,however, touch panel 13 is not limited to the resistive type and variouspressing-type touch panels may be adopted. In addition, resolution(detection accuracy) of touch panel 13 is preferably as high asresolution (display accuracy) of first LCD 12. It is noted, however,that the resolution of touch panel 13 does not necessarily have to beequal to the resolution of first LCD 12.

An insertion opening (shown with a dashed line in FIG. 1) for a touchpen 27 is provided in a right side surface of first housing 11. Touchpen 27 used for performing an input operation on touch panel 13 can beaccommodated in the insertion opening. Normally, the input operation ontouch panel 13 is performed by using touch pen 27, however, the inputoperation onto touch panel 13 can be performed also by using a finger ofthe user or the like instead of touch pen 27.

Moreover, an insertion opening (shown with a chain-double-dotted line inFIG. 1) for accommodating a memory card 28 is provided in the right sidesurface of first housing 11. A connector (not shown) for electricallyconnecting game device 100 and memory card 28 with each other isprovided in the inside of this insertion opening. Memory card 28 isremovably attached to the connector. Memory card 28 is used for readinga program or image data obtained from another information processingdevice or game device, storing (saving) data of an image photographedand/or subjected to image processing by game device 100, and the like.Memory card 28 is implemented, for example, by a non-volatile storagemedium such as an SD (Secure Digital) card.

An insertion opening (shown with a chain-dotted line in FIG. 1) foraccommodating a memory card 29 is provided in the upper side surface offirst housing 11. A connector (not shown) for electrically connectinggame device 100 and memory card 29 with each other is provided in theinside of this insertion opening. Memory card 29 is removably attachedto the connector. Memory card 29 stores an application program, a gameprogram or the like.

Three LEDs 15A to 15C are disposed in a portion on the left of thecoupling portion of first housing 11 and second housing 21. As will bedescribed later, game device 100 can establish wireless communicationwith other equipment, and a first LED 15A illuminates when the power ofgame device 100 is turned on. A second LED 15B illuminates depending ona status of a battery (for example, being charged or a low batterylevel) of game device 100. A third LED 15C illuminates depending on astatus of wireless communication. Therefore, three LEDs 15A to 15C cannotify the user of a state of power on/off of game device 100, a stateof battery, and a state of wireless communication.

A second LCD 22 is provided in second housing 21 as the display portion(display means). Second LCD 22 has a rectangular shape and it isarranged such that a direction in which its long side extends coincideswith a direction in which a long side of second housing 21 extends. Asin first LCD 12, another appropriate display device may be employedinstead of the LCD. In game device 100, such a configuration that atouch panel serving as the input means (input portion) is attached tocover a screen of first LCD 12 is adopted, however, yet another touchpanel may be attached onto a screen of second LCD 22.

In addition, two cameras (an inner camera 23 and an outer camera 25)each serving as the image pick-up means (image pick-up device) areprovided in second housing 21. As shown in FIG. 1, inner camera 23 isdisposed in an inner main surface of second housing 21 around thecoupling portion. On the other hand, as shown in FIG. 2, outer camera 25is disposed in a surface opposite to the inner main surface where innercamera 23 is disposed, that is, in an outer main surface of secondhousing 21 (a surface on the outside when game device 100 is in theclosed state). In FIG. 1, outer camera 25 is shown with a dashed line.

According to such arrangement, inner camera 23 can pick up an image in adirection in which the inner main surface of second housing 21 faces,and outer camera 25 can pick up an image in a direction opposite to thedirection of image pick-up by inner camera 23, that is, in a directionin which the outer main surface of second housing 21 faces.

In this manner, in game device 100 according to the present embodiment,inner camera 23 and outer camera 25 are provided such that thedirections of image pick-up are opposite to each other. Therefore, theuser can pick up with inner camera 23, an image of the userhimself/herself and also can pick up with outer camera 25, an image of aview the user is viewing, while holding game device 100. It is notedthat the user can select which camera to use for image pick-up, on aprogram executed in game device 100.

A microphone (a microphone 43 shown in FIG. 3) is accommodated as anaudio input device inside the coupling portion of game device 100. Inthe inner main surface around the coupling portion of game device 100, amicrophone hole 16 is provided such that microphone 43 senses soundaround game device 100. A position where microphone 43 is accommodatedand a position of microphone hole 16 do not necessarily have to be inthe coupling portion of game device 100, and for example, microphone 43may be accommodated in first housing 11 and microphone hole 16 may beprovided in first housing 11 in correspondence with the position ofaccommodation of microphone 43.

A fourth LED 26 (FIG. 2) is disposed in the outer main surface of secondhousing 21 at a position proximate to outer camera 25. Fourth LED 26illuminates depending on a status of image pick-up by outer camera 25.Namely, fourth LED 26 notifies a person or a person nearby in the fieldthat the image pick-up by game device 100 is being performed. Morespecifically, fourth LED 26 illuminates while outer camera 25 is pickingup an image. In addition, fourth LED 26 may blink while a motion pictureis being taken (data of picked-up images is continuously stored) byouter camera 25. In order to prevent illumination of the LED fromentering the image pick-up screen, fourth LED 26 may be turned offduring a period from a time point of instruction of photographing withthe camera until completion of storage of the image data obtained by thecamera in response to the instruction into a memory or the like.

A sound emission hole 24 is provided in the main surface of secondhousing 21, on each of left and right sides of second LCD 22 providedaround the center of the inner main surface. A speaker (a speaker 45shown in FIG. 3) serving as an audio output device is accommodated insecond housing 21 communicating with sound emission hole 24. Namely,sound emission hole 24 guides sound emitted from speaker 45 to theoutside of game device 100.

As described above, first housing 11 is provided with the input portion(touch panel 13 and buttons 14A to 14K) for providing operation inputsto game device 100 as well as first LCD 12 serving as the display meansfor displaying various images. In addition, second housing 21 isprovided with inner camera 23 and outer camera 25 for obtaining imagedata as well as second LCD 22 serving as the display means fordisplaying various images.

First LCD 12 and/or second LCD 22 is (are) used for displaying, in realtime, an image obtained by inner camera 23 or outer camera 25 asnecessary. Namely, first LCD 12 and/or second LCD 22 function(s) as a“finder” in picking up an image with inner camera 23 or outer camera 25.It is noted that an image successively obtained by inner camera 23 orouter camera 25 and displayed on first LCD 12 and/or second LCD 22, thatis, an image updated in real time, is also referred to as a “Liveimage”.

<Internal Configuration of Game Device>

Referring to FIG. 3, game device 100 includes such electronic parts as aCPU 31, a main memory 32, a memory control circuit 33, a data memory 34for storage, a memory 35 for preset data, memory card interfaces (memorycard I/F) 36 and 37, a wireless communication module 38, a localcommunication module 39, a real time clock (RTC) 40, a power supplycircuit 41, and an interface circuit (I/F circuit) 42. These electronicparts are mounted on an electronic circuit board and accommodated infirst housing 11 (or second housing 21).

CPU 31 is an operation processing unit for executing various programs.CPU 31 develops a program stored in any of the memory in game device 100(typically, data memory 34 for storage), memory card 28 (FIG. 1) andmemory card 29 (FIG. 1) on main memory 32, and executes the program. Asa result of execution of the program by CPU 31, various types ofprocessing according to the present embodiment which will be describedlater are provided. As will be described later, the program according tothe present embodiment is typically supplied from a distribution serverdevice network-connected through a wired or wireless communicationchannel to game device 100. The program supplied to game device 100 isstored in data memory 34 for storage.

In addition, CPU 31 has a not-shown VRAM (Video Random Access Memory)for exclusively controlling display on first LCD 12 and second LCD 22.The VRAM temporarily stores image data or the like for displayingvarious images which will be described later. It is noted that datastored in main memory 32 is transferred to the VRAM, or a file (data) orthe like stored in data memory 34 for storage is directly read and thecontent thereof is written in the VRAM.

Referring to FIG. 4, a typical system for distributing a programaccording to the present embodiment includes a distribution serverdevice SRV connected to a network NW such as the Internet and an accesspoint AP for mediating wireless communication of game device 100 withnetwork NW. Distribution server device SRV holds a plurality of programsincluding the program according to the present embodiment in adownloadable state, and it starts transmission (downloading) of arequested program in response to access from game device 100 or thelike, after a prescribed procedure is completed.

Access point AP is wire-connected to network NW and establishes wirelessconnection with wireless communication module 38 (FIG. 3). Game device100 accesses distribution server device SRV through this access pointAP. Receiving the program distributed from distribution server deviceSRV as described above, CPU 31 of game device 100 causes data memory 34for storage to store the received program. Transfer to the outside ofgame device 100, of the program once stored in data memory 34 forstorage of game device 100, is in principle prohibited. Therefore, theprogram once taken into game device 100 is executed only in game device100. Thus, various settings, parameters and the like can be customizedor arranged originally for game device 100, in accordance with recordsof use or a manner of use by the owner of game device 100.

Instead of the network distribution configuration as shown in FIG. 4, aprogram may be provided by selling memory card 28 or memory card 29having the program stored thereon. Here, a non-transitory storage mediumfor storing the program according to the present invention is notlimited to a semiconductor memory device such as memory card 28 ormemory card 29, and an optical storage medium such as a CD-ROM or a DVDmay be adopted.

Referring again to FIG. 3, main memory 32, memory control circuit 33 andmemory 35 for preset data are connected to CPU 31. In addition, datamemory 34 for storage is connected to memory control circuit 33.

Main memory 32 is storage means used as a work area or a buffer area ofCPU 31. Namely, main memory 32 temporarily stores data used for varioustypes of processing or temporarily stores a program read and developedfrom data memory 34 for storage, memory card 28, memory card 29, and thelike. In the present embodiment, for example, a PSRAM (Pseudo-SRAM) isemployed as main memory 32.

Data memory 34 for storage is storage means for storing a programexecuted by CPU 31, data of images picked up by inner camera 23 andouter camera 25, and the like. Data memory 34 for storage is implementedby a non-volatile storage medium such as a NAND-type flash memory.Memory control circuit 33 is a circuit for controlling reading andwriting of data from/to data memory 34 for storage in accordance with aninstruction from CPU 31.

Memory 35 for preset data is storage means for storing data such asvarious parameters set in advance in game device 100 (preset data). Aflash memory connected to CPU 31 through an SPI (Serial PeripheralInterface) bus may be employed as memory 35 for preset data.

Memory card I/Fs 36 and 37 are each connected to CPU 31. Memory card I/F36 performs reading and writing of data from/to memory card 28 attachedto the connector in response to an instruction from CPU 31. In addition,memory card I/F 37 performs reading and writing of data from/to memorycard 29 attached to the connector in response to an instruction from CPU31.

In the present embodiment, data of images obtained by inner camera 23and outer camera 25 or image data obtained from other devices is writtenin memory card 28 through memory card IN 36, or image data stored inmemory card 28 is read from memory card 28 through memory card I/F 36and written as a file in data memory 34 for storage. In addition,various programs stored in memory card 29 are read from memory card 29through memory card I/F 37 and written in main memory 32.

Wireless communication module 38 has a function for connection towireless LAN, for example, in compliance with IEEE 802.11.b/gspecifications. In addition, local communication module 39 has afunction to establish wireless communication with a game device of asimilar type under a prescribed communication scheme. Wirelesscommunication module 38 and local communication module 39 are connectedto CPU 31. CPU 31 can transmit and receive data to/from other equipmentthrough a network circuit such as the Internet by using wirelesscommunication module 38, or transmit and receive data to/from anothergame device of a similar type by using local communication module 39.

In addition, RTC 40 and power supply circuit 41 are connected to CPU 31.RTC 40 counts time and outputs the counted time to CPU 31. For example,CPU 31 is also able to calculate current time (date) or the like basedon the time counted by RTC 40. Power supply circuit 41 controls electricpower supplied from a power supply of game device 100 (typically, abattery housed in first housing 11) and supplies electric power to eachpart of game device 100.

Game device 100 further includes I/F circuit 42 connected to CPU 31.Microphone 43, an amplifier 44 and touch panel 13 are connected to I/Fcircuit 42. I/F circuit 42 includes an audio control circuit forcontrolling microphone 43 and amplifier 44 (and speaker 45) and a touchpanel control circuit for controlling touch panel 13.

Microphone 43 senses voice and sound of the user issued toward gamedevice 100 and outputs an audio signal indicating the sensed voice andsound to I/F circuit 42. Amplifier 44 amplifies the audio signal fromI/F circuit 42 and causes the audio signal to be output from speaker 45.Namely, the audio control circuit included in I/F circuit 42 performsA/D conversion of the audio signal sensed by microphone 43 and outputsthe result to CPU 31, as well as performs D/A conversion of a signalgenerated by CPU 31 or the like and outputs the result to amplifier 44.Moreover, the audio control circuit converts the audio signal to audiodata in a prescribed format suitable for storage.

In addition, the touch panel control circuit included in I/F circuit 42generates touch position data based on a detection signal from touchpanel 13 and outputs the data to CPU 31. For example, the touch positiondata includes a coordinate value indicating a position where input to aninput surface of touch panel 13 was made (hereinafter also referred toas an “input coordinate”). It is noted that the touch panel controlcircuit cyclically performs reading of a signal from touch panel 13 andgeneration of the touch position data in a prescribed period of time.CPU 31 can detect an input coordinate on which the user's inputoperation of touch panel 13 was performed, by obtaining the touchposition data through I/F circuit 42 (touch panel control circuit).

Button 14 collectively represents buttons 14A to 14K described above andit is connected to CPU 31. Operation data indicating a state of input toeach of buttons 14A to 14K (whether the button was pressed or not) isoutput from button 14 to CPU 31. CPU 31 performs processing inaccordance with the user's operation of button 14 by obtaining theoperation data from button 14.

Inner camera 23 and outer camera 25 are each connected to CPU 31. Innercamera 23 and outer camera 25 pick up an image in response to aninstruction from CPU 31 and output data of the image obtained by imagepick-up to CPU 31. Each of inner camera 23 and outer camera 25 includesan image pick-up element such as CCD (Charge Coupled Device) or CIS(CMOS Image Sensor) and a peripheral circuit for reading image dataobtained by the image pick-up element. For example, CPU 31 issues animage pick-up instruction to any one of inner camera 23 and outer camera25, and the camera that received the image pick-up instruction outputsthe obtained image data to CPU 31.

In addition, first LCD 12 and second LCD 22 are each connected to CPU31. First LCD 12 and second LCD 22 display an image in response to aninstruction from CPU 31. In one embodiment, CPU 31 causes one of firstLCD 12 and second LCD 22 to display the image obtained by inner camera23 or outer camera 25, and causes the other of first LCD 12 and secondLCD 22 to display a screen (image) for accepting the user's operationand/or providing the user with operation guidance.

<Overview of Provided Interactive Application>

Initially, overview of an interactive application provided by executionof the program according to the present embodiment will be describedwith reference to FIG. 5. With the interactive application according tothe present embodiment, image display adapted to a case where firsthousing 11 and second housing 21 are spread on left and right sides whenviewed from the user is provided.

Referring to FIG. 5, initially, when CPU 31 executes the programaccording to the present embodiment, a state ST2 is set as an initialstate. It is noted that game device 100 can selectively execute aprogram stored within the device, memory card 28, and memory card 29.Accordingly, when power is turned on, initially, a launcher program forselecting a program (application) to be started up is executed in gamedevice 100. The user selects and starts up a desired program on alauncher screen displayed on first LCD 12 and second LCD 22 by executingthe launcher program.

FIG. 6 is a diagram showing an exemplary title menu (at the time ofstart-up for the first time) according to the embodiment of the presentinvention. FIGS. 7A and 7B are diagrams showing exemplary title menus(for the second time or later) according to the embodiment of thepresent invention. It is noted that FIGS. 6, 7A and 7B integrally showthe entire images (screen shots) displayed on first LCD 12 and secondLCD 22 respectively, for the sake of convenience of illustration. Inaddition, though FIGS. 6, 7A and 7B show that game device 100 is heldsuch that first LCD 12 is located on the right and second LCD 22 islocated on the left when viewed from the user, relative relation betweenfirst LCD 12 and second LCD 22 when viewed from the user can be reversedin game device 100 (rotation by 180 degrees). Namely, as will bedescribed later, in which orientation first LCD 12 and second LCD 22should be located when viewed from the user can be switched, dependingon user's handedness. Therefore, depending on a manner of use by theuser, display contents on first LCD 12 and display contents on secondLCD 22 may be interchanged. This is also the case with different entireimages (screen shots) displayed on first LCD 12 and second LCD 22respectively as shown below.

In game device 100 according to the present embodiment, as touch panel13 is provided only on first LCD 12, there may be a case that displaycontents on first LCD 12 and display contents on second LCD 22 are notinterchanged. For example, when a user's touch operation input isprovided, display contents on first LCD 12 and second LCD 22 areinverted. In addition, when an image is displayed across first LCD 12and second LCD 22, the entire image is inverted and then the displaycontents on respective LCDs are interchanged.

Referring to FIG. 6, according to the program of the present embodiment,the interactive application (hereinafter simply also referred to as an“application”) proceeds, with use by the owner user of game device 100(hereinafter simply also referred to as the “owner”) being distinguishedfrom use by an unspecified user who is not the owner of game device 100(hereinafter also referred to as a “guest”). It is noted that a familymember, a friend or the like of the owner is assumed as a guest.

Namely, in response to the user's operation on the title menu shown inFIG. 6, one of an owner mode (a first mode) and a guest mode (a secondmode) is set and a selected application (or a game) proceeds inaccordance with the set mode. More specifically, as an “owner” image 102displayed on the title menu is touched with touch pen 27, a finger ofthe user himself/herself, or the like (hereinafter simply also referredto as “touch pen 27 etc”), the owner mode is set. Then, transition amongstates shown with states ST4 to ST14 (FIG. 5) is made in response to theuser's operation. On the other hand, as a “family and friend” image 106displayed on the title menu is touched with touch pen 27 etc., the guestmode is set. Then, transition among states shown with ST20 to ST36 (FIG.5) is made in response to the user's operation.

Thus, by executing the program according to the present embodiment, CPU31 provides a setting function for setting any of the owner mode (firstmode) and the guest mode (second mode) in response to the user'soperation and a proceeding function for proceeding with the interactiveapplication in response to the user's operation.

It is noted that images 102 and 106 are displayed on first LCD 12,because touch panel 13 serving as the input means is provided only onfirst LCD 12 in the present embodiment. When the user touches a positionon first LCD 12 where image 102 or 106 is displayed with touch pen 27etc., a corresponding instruction is accepted.

When the owner mode is set, a result obtained by subsequent execution ofthe application (typically, performance, an image hand-drawn by eachuser, or the like) is stored in association with the owner. On the otherhand, when the guest mode is set, a result obtained by subsequentexecution of the application is stored in association with any guest. Itis noted that a plurality of guest accounts are preferably prepared.

Thus, by executing the program according to the present embodiment, CPU31 provides a storage function for storing, in cooperation with datamemory 34 for storage, a result obtained by executing the interactiveapplication.

In particular, the result obtained in the owner mode is stored togetherwith the result previously obtained in the owner mode, in associationwith the owner registered in advance, for chronologically displayinghistory of results of repeated play of the same application by theowner. In other words, as the play in the owner mode can be regarded asplay by a specific user (the owner of game device 100), the resultsrelating to the specific user can consistently be stored and managed.

On the other hand, the results obtained in the guest mode are stored inassociation with an account of any guest, independently of the resultsobtained previously in the guest mode. Namely, the results of play ofthe application in the guest mode are stored each time, in associationwith the account of any guest. The accounts of the guests, however, arenot associated with each other, and hence only a one-time play result isstored for each guest account.

In the account of the owner described above, identification informationindicating the owner (hereinafter also referred to as “owneridentification information”) is registered in advance. Namely, if theowner identification information has not been registered when image 102is touched with touch pen 27 etc on the title menu shown in FIG. 6(state ST2 in FIG. 5), as shown in FIG. 5, processing for checking“handedness” of the owner (state ST16) is performed and thereaftertransition to processing for registering the owner identificationinformation (state ST18) is made. The owner identification informationregistered in this state ST18 includes a face image indicating the owner(a head shot or a self-portrait), a signature of the owner, a date ofbirth of the owner, and the like. As will be described later, accordingto the application of the present embodiment, one of the head shot andthe self-portrait of the owner can be registered as the face image,depending on whether a situation permits photographing with a camera ornot.

Thus, by executing the program according to the present embodiment, CPU31 provides a first identification information input function foraccepting input of owner identification information (firstidentification information) when the owner identification information(first identification information) has not been stored in the storagemeans. In addition, by executing the program according to the presentembodiment, CPU 31 provides a storage function for storing an image inassociation with user information and a determination function fordetermining whether a situation permits photographing with the imagepick-up means or not.

Namely, in game device 100 according to the present embodiment, when theowner identification information (first identification information) hasbeen stored in the storage means, an application is started withoutrequest of input of new first identification information, whereas whenthe owner identification information (first identification method) hasnot been stored in the storage means, the interactive application isstarted on condition that the first identification information is input.

FIG. 6 shows an exemplary title menu displayed when the applicationaccording to the present embodiment is started up for the first time ordisplayed after the registered owner identification information wasinitialized (erased). In this case, as owner identification informationhas not been registered, a default image 104 instead of a face imageindicating the owner is displayed in “owner” image 102 in the titlemenu. When a head shot of the owner is subsequently obtained inprocessing for registering owner identification information, the titlemenu as shown in FIG. 7A is displayed. In the title menu shown in FIG.7A, a head shot 104A indicating the registered owner is displayed in“owner” image 102.

On the other hand, when the owner hand-draws a self-portrait instead ofphotographing with the camera in the processing for registering owneridentification information, the title menu as shown in FIG. 7B isdisplayed. In the title menu shown in FIG. 7B, a self-portrait 104B ofthe registered owner is displayed in “owner” image 102.

In addition, when “owner” image 102 is touched with touch pen 27 etc. inthe title menu shown in FIGS. 6, 7A and 7B, a main menu for the owner asshown in FIG. 8 is displayed. On the other hand, when “family andfriend” image 106 is touched with touch pen 27 etc. in the title menushown in FIGS. 6, 7A and 7B, processing for checking “handedness” of acurrent guest (state ST20) is performed and thereafter a main menu for aguest as shown in FIG. 9 is displayed.

In the main menu for the owner shown in FIG. 8, a signature image 202 ofthe owner and a face image (head shot or self-portrait) 204 of theowner, which represent a part of the owner identification information,are displayed and a part of results obtained by execution of theapplication by the owner is displayed. More specifically, an image 206indicating a value of a “brain age” representing a result of a checkgame which will be described later is displayed and a “stamp”acquisition state 208 indicating records of play of a training gamewhich will be described later is displayed. The “stamp” acquisitionstate corresponds to history information in accordance with records ofplay by the user.

In the main menu for the owner shown in FIG. 8, a “training” image 210,a “theme” image 212, a “brain age check” image 214, and an “option”image 216 are further displayed. When “training” image 210 is touchedwith touch pen 27 etc., the training game which will be described lateris started (state ST6 in FIG. 5). A result of this training game isstored in correspondence with the owner. Alternatively, when “theme”image 212 is touched with touch pen 27 etc., an association game whichwill be described later is started (state ST8 in FIG. 5). A result ofthis association game is stored in correspondence with the owner anddisplayed on first LCD 12 and/or second LCD 22 (state ST10 in FIG. 5).Alternatively, when “brain age check” image 214 is touched with touchpen 27 etc., a check game which will be described later is started(state ST12 in FIG. 5). A result of this check game is stored incorrespondence with the owner and displayed on first LCD 12 and/orsecond LCD 22 (state ST14 in FIG. 5). When “option” image 216 is touchedwith touch pen 27 etc., various types of processing other than the gameare performed.

Thus, by executing the program according to the present embodiment, CPU31 provides a first display control function for displaying result datain the owner mode in correspondence with the owner identificationinformation (first identification information).

On the other hand, in the main menu for the guest shown in FIG. 9, anotification image 302 as well as a “training” image 310, a “theme”image 312 and a “brain age check” image 314 are displayed.

Notification image 302 shows a message notifying the user that a resultof the training game played by the guest is not stored but a result ofthe association game and the check game is stored.

When “training” image 310 is touched with touch pen 27 etc., thetraining game which will be described later is started (state ST24 inFIG. 5). A result of this training game is merely displayed and notstored. It is noted that a content (a scenario) itself of the traininggame provided to the guest is substantially the same as the content ofthe training game provided to the owner. Alternatively, when “theme”image 312 is touched with touch pen 27 etc., the association game whichwill be described later is started (state ST26 in FIG. 5). A result ofthis association game is stored in correspondence with any of aplurality of guest accounts prepared in advance. Here, identificationinformation indicating a guest who actually played the game (hereinafteralso referred to as “guest identification information”) is registered(state ST28 in FIG. 5). The guest identification information registeredin this state ST28 includes a signature of the guest and the like. Theresult of the association game is stored in correspondence with theregistered guest (guest identification information) and displayed onfirst LCD 12 and/or second LCD 22 (state ST30 in FIG. 5). Alternatively,when “brain age check” image 314 is touched with touch pen 27 etc., thecheck game which will be described later is started (state ST32 in FIG.5). A result of the check game is stored in correspondence with any ofthe plurality of guest accounts prepared in advance. Here, the guestidentification information for specifying the guest user who actuallyplayed the game is registered (state ST34 in FIG. 5). The guestidentification information registered in this state ST34 includes a faceimage (head shot or self-portrait) indicating the guest and the like. Itis noted that one of the head shot and the self-portrait can be selectedand registered as the face image indicating the guest, depending onwhether a situation permits photographing with the camera or not, as inregistration of the face image indicating the owner described above. Aresult of the check game is stored in correspondence with the registeredguest (guest identification information) and displayed on first LCD 12and/or second LCD 22 (state ST36 in FIG. 5).

Thus, by executing the program according to the present embodiment, CPU31 provides a second identification information input function foraccepting input of guest identification information (secondidentification information) indicating the user who executed theinteractive application each time the interactive application isexecuted while the guest mode (second mode) is set and a second displaycontrol function for causing result data in the guest mode to bedisplayed in correspondence with the guest identification information(second identification information).

<Data Structure>

Referring to FIG. 10, game device 100 stores an owner_face image file402, an owner_signature image file 404, an owner_setting file 406, atraining data file 408, an owner_theme file 430, a guest_face image file442, a guest_signature image file 452, a guest_brain age file 444, and aguest_theme file 454. It is noted that these files are in principlestored in data memory 34 for storage or memory 35 for preset data (FIG.3).

Contents of the owner identification information are stored inowner_face image file 402, owner_signature image file 404 andowner_setting file 406. More specifically, image data representing theface image (head shot or self-portrait) of the owner is stored inowner_face image file 402. Image data representing a signaturehandwritten by the owner is stored in owner_signature image file 404.Handedness setting and a date of birth of the owner are stored inowner_setting file 406.

Results of the training game and the check game which will be describedlater are stored in training data file 408. More specifically,owner_brain age data 410 indicating a result of the check game for Ndays is stored in training data file 408. Namely, owner_brain age data410 corresponds to a data group indicating results of the check game forN days. It is noted that the results of the check game typically includesuch a value as “20” years of age and information on time (time and dayof play) when the check game was played. In addition, owner_training Aperformance data 420A and owner_training A time data 422A,owner_training B performance data 420B and owner_training B time data422B, . . . are stored in training data file 408, in correspondence withtraining games A, B, . . . prepared in advance, respectively. Forexample, performance of training A (typically, time required forfinishing a calculation game, percentage of correct answers, and thelike) is stored in owner_training A performance data 420A. The totaltime required for play of training A is stored in owner_training A timedata 422A. Hereinafter, owner_training A performance data 420A, trainingB performance data 420B, . . . are collectively referred to as“owner_training performance data 420,” and owner_training A time data422A, owner_training B time data 422B, . . . are collectively referredto as “owner_training time data 422.”

Image data (camera image or hand-drawn image) or audio data brought incorrespondence with a “theme” (themes 1, 2, . . . ) prepared in advancefor the association game which will be described later is stored inowner_theme file 430. As owner_theme file 430 is generated when theassociation game is played, owner_theme file 430 is not generated for a“theme” which has not yet been played. It is noted that null files maybe generated in advance in correspondence with all “themes” prepared inadvance and a file of interest may be updated in accordance with aresult of play of the association game.

Contents of the guest identification information are stored inguest_face image file 442 and guest_signature image file 452. It isnoted that seven guest_face image files 442 are prepared for sevenguests in total of guest 1 to guest 7 respectively, and a prescribednumber of (for example, five) guest_signature image files 452 areprepared for each “theme” (themes 1, 2, . . . ) prepared in advance. Aswill be described later, guest_face image file 442 is used forassociation with the guest in storing a result of play of the check gameby the user other than the owner, and guest_signature image file 452 isused for association with the guest in storing a result of play of theassociation game by the user other than the owner. Namely, the resultsobtained when the same user actually played the check game and theassociation game as the guest are handled as results of guestsindependent of each other.

More specifically, image data representing the face image (head shot orself-portrait) of the guest is stored in each guest_face image file 442.Image data representing a signature handwritten by the guest is storedin each guest_signature image file 452. It is noted that handednesssetting or a date of birth is not registered for the guest, as in thecase of the owner.

The results of the check game for seven persons are stored inguest_brain age file 444, in correspondence with the accounts of guests1 to 7, respectively. It is noted that the result of each guestrepresents in principle a value obtained in one check game. In addition,each result brought in correspondence with the account of each of guests1 to 7 is handled independently.

Image data (camera image or hand-drawn image) or audio data brought incorrespondence with a “theme” (themes 1, 2, . . . ) prepared in advancefor the association game which will be described later is stored inguest_theme file 454. Guest_signature image file 452 is generated inassociation with each guest_theme file 454 on one-to-one basis.Therefore, when the same user plays different “themes”, independentguest_signature image files 452 are generated for respective results ofplay. Namely, guest_theme file 454 and guest_signature image file 452can both independently store results of play of each “theme” prescribednumber of times (for example, for five persons).

When the user is caused to input a plurality of pieces of image data(camera image or hand-drawn image) or audio data for one “theme” or whenthe user is caused to successively play a plurality of “themes”,resultant plurality of guest_theme files 454 may be brought incorrespondence with the same guest_signature image file 452 (that is, nto 1). In such a case, guest_signature image file 452 input at thebeginning of consecutive plays may commonly be employed.

It is noted that the “brain age” values of guests 1 to 7 stored inguest_brain age file 444 are associated with guests 1 to 7 of which faceimages are stored in guest_face image file 442, respectively. Therefore,if eight or more guests play the check game, a result of any guestshould be erased. Here, for example, when guest 1 is an erase target,“guest 1_brain age file” and “the brain age value of guest 1” stored inguest_brain age file 444 are both erased (or overwritten).

Similarly, guest_theme file 454 about each “theme” is associated withguest_signature image file 452 on one-to-one basis. Therefore, whenguests in number exceeding a prescribed number (for example, five) playthe association game, a result of any guest should be erased. Here, forexample, when guest 8 is an erase target, “guest 8_theme 1 file” and“guest 8 signature image file” brought in correspondence therewith areboth erased (or overwritten).

In addition, in the present embodiment, three interactive applicationsof the check game, the training game and the theme are prepared, andresult data is stored in association with the owner or the guest(s),independently of each interactive application.

<Processing for Checking Handedness>

As described above, with the application according to the presentembodiment, mainly, game device 100 is held for use in such a state thatfirst housing 11 and second housing 21 are spread on left and rightsides when viewed from the user. Here, in game device 100, touch panel13 serving as the input means is provided on first housing 11.Accordingly, preferably, a position of touch panel 13 relative to theuser is switched in accordance with user's handedness (right handednessor left handedness). Namely, for a right-handed user, touch panel 13 ispreferably located on the right side, whereas for a left-handed user,touch panel 13 is preferably located on the left side. According to theapplication of the present embodiment, for the owner, his/her handednessis checked immediately before registration of the owner identificationinformation (state ST16 in FIG. 5) and for a guest, his/her handednessis checked at the timing regarded as start of use by a new guest (forexample, immediately before display of the main menu) (state ST20 inFIG. 5).

When the owner mode is selected and when owner identificationinformation (owner_face image file 402, owner_signature image file 404and owner_setting file 406 shown in FIG. 10) has not been registered(typically, at the time of start-up of the application for the firsttime), a screen for checking handedness as shown in FIG. 11 isdisplayed. In addition, when the guest mode is selected as well, ascreen for checking handedness as shown in FIG. 11 is displayed.

In the screen shown in FIG. 11, together with a notification image 124inviting the user to input handedness, an “R” image 122 for acceptingselection of right handedness and an “L” image 120 for acceptingselection of left handedness are displayed.

When one of “R” image 122 and “L” image 120 is touched with touch pen 27etc., transition to screen display in accordance with a manner of use asshown in FIG. 12A or 12B is made. FIG. 12A shows a manner of use whenthe user is right-handed (when “R” image 122 is selected) and FIG. 12Bshows a manner of use when the user is left-handed (when “L” image 120is selected).

Referring to FIG. 12A, typically, the right-handed user can hold gamedevice 100 with his/her left forefinger abutting second housing 21.Then, the right-handed user performs the input operation on touch panel13 provided in first housing 11 with the right hand or touch pen 27operated with the right hand.

On the other hand, referring to FIG. 12B, typically, the left-handeduser can hold game device 100 with his/her right forefinger abuttingfirst housing 11. Then, the left-handed user performs the inputoperation on touch panel 13 provided in first housing 11 with the lefthand or touch pen 27 operated with the left hand. Namely, theorientation in which the left-handed user holds game device 100corresponds to the orientation rotated by 180 degrees from theorientation in which the right-handed user holds game device 100.

By using game device 100 in a manner as described above, visualrecognition of display contents on second LCD 22 provided in secondhousing 21 will not be blocked by the input operation, regardless ofwhether the user is either right-handed or left-handed.

As described above, as touch panel 13 is provided in first housing 11,an instruction image BTN representing a button or the like for acceptinga user's input operation is displayed on first LCD 12, regardless ofwhether the user is either right-handed or left-handed. A direction ofdisplay, however, should be rotated by 180 degrees in accordance withthe user's handedness, as in the direction in which game device 100 isheld.

In addition, game device 100 incorporates a camera (inner camera 23 andouter camera 25) as described above. Inner camera 23 is arranged suchthat a face portion of the user is included in its field while the userholds game device 100. Accordingly, the user's head shot obtained bythis inner camera 23 is used as the owner identification information oras the guest identification information. Such a camera image IMGobtained through image pick-up by the camera is displayed on second LCD22 provided in second housing 21 in many cases. Such camera image IMGshould also be rotated by 180 degrees in accordance with the user'shandedness.

Namely, as can be seen from comparison between FIGS. 12A and 12B, atleast instruction image BTN and camera image TMG are displayed afterthey are rotated by 180 degrees in accordance with the user'shandedness.

<Processing for Image Pick-up/Display in Accordance With Handedness>

As described above, the direction in which the user holds game device100 is rotated by 180 degrees, depending on the user's handedness. Here,relative relation between inner camera 23 arranged in the couplingportion of second housing 21 and second LCD 22 is not varied. Therefore,in order to display camera image IMG in correspondence with any of FIGS.12A and 12B, image data obtained through image pick-up by inner camera23 may be read in a fixed direction and displayed on second LCD 22,regardless of the direction in which game device 100 is held.

If such a scheme is adopted, however, the orientation of data of theimage photographed by inner camera 23 is rotated by 180 degrees inaccordance with the direction in which game device 100 is held.Therefore, in displaying (reproducing) or editing the data of the imagethus photographed, rotation correction in accordance with the directionin which game device 100 is held at the time of photographing should becarried out. Accordingly, processing in an operation for displaying orediting photographed image data may become complicated.

In game device 100 according to the present embodiment, regardless ofthe direction in which game device 100 is held, the image data isrotated by 180 degrees as necessary such that the subject (typically,the user himself/herself holding game device 100) faces the samedirection and the resultant image data is stored. More specifically, adirection of reading the image data from inner camera 23 is switchedsuch that the user's face that appears in the image data picked up byinner camera 23 while the right-handed user holds game device 100 andthe user's face that appears in the image picked up by inner camera 23while the left-handed user holds game device 100 are oriented in thesame direction.

FIGS. 13A and 13B are diagrams for illustrating overview of processingfor image pick-up/display with the use of the inner camera according tothe embodiment of the present invention. FIGS. 14A and 14B are diagramsfor illustrating display processing according to the embodiment of thepresent invention. It is noted that FIGS. 13A and 13B and FIGS. 14A and14B are based on the manner of use where the user is right-handed,however, they may be based on the manner of use where the user isleft-handed.

Referring to FIG. 13A, it is assumed that, when the right-handed userholds game device 100, an image of the subject (the user himself/herselfholding game device 100) is incident on an image pick-up element 23A ofinner camera 23, with his/her head up in the drawing. Then, image datarepresenting the image is successively read from image pick-up element23A, with the upper left end of the drawing being defined as thestarting point and the lower right end of the drawing being defined asthe end point.

According to such a configuration, when the left-handed user holds gamedevice 100, an image of the subject (the user himself/herself of gamedevice 100) is incident on image pick-up element 23A of inner camera 23,with his/her head down in the drawing, as shown in FIG. 13B. Here, imagedata representing the image is successively read from image pick-upelement 23A, with the lower right end of the drawing being defined asthe starting point and the upper left end of the drawing being definedas the end point.

By switching between the directions of reading from image pick-upelement 23A as described above, the user himself/herself of game device100 always appears in the same orientation on image data SIMG stored inmain memory 32 or data memory 34 for storage, regardless of thedirection in which game device 100 is held.

In addition, in displaying such image data SIMG on first LCD 12 and/orsecond LCD 22, read image data SIMG is rotated by 180 degrees asnecessary and then displayed. For example, as shown in FIG. 13A, it isassumed that read image data SIMG is displayed with its orientationremaining the same when the right-handed user holds game device 100.Then, as shown in FIG. 13B, when the left-handed user holds game device100, read image data SIMG is displayed in the orientation after rotationby 180 degrees. Namely, when right handedness is set, read image dataSIMG is displayed as camera image DIMG identical in the orientation,whereas when left handedness is set, read image data SIMG is displayedas camera image DIMG having the orientation rotated by 180 degrees.

In addition, the instruction image representing the button or the likefor accepting the user's input operation is also displayed after it isrotated by 180 degrees as necessary. Processing for displaying thecamera image and the instruction image will be described hereinafterwith reference to FIGS. 14A and 14B.

FIG. 14A shows processing when right handedness is set, while FIG. 14Bshows processing when left handedness is set.

As shown in FIGS. 14A and 14B, in game device 100, a video signal fordisplaying an image on first LCD 12 and second LCD 22 is generated withthe use of a plurality of layers. More specifically, a video signal fordisplay control for first LCD 12 is generated by a layer LYR1-1reflecting a camera image and LYR2-1 reflecting an instruction image(e.g. ENTER). Similarly, a video signal for display control for secondLCD 22 is generated by a layer LYR1-2 reflecting a camera image andLYR2-2 reflecting an instruction image. It is noted that each of layersLYR1-1 to 2-2 is provided by allocating a memory area sufficiently largefor display on first LCD 12 or second LCD 22 in the VRAM (not shown)within CPU 31

It is noted that such different layers are provided for the camera imageand the instruction image because the camera image should be updated ina relatively short cycle, whereas it is not necessary in principle toupdate the instruction image unless some kind of event occurs, Namely,the layers are provided in order to efficiently utilize machineresources required for image processing (for example, polygon processingand the like), in accordance with a necessary update cycle. It is notedthat a single layer may realize rendering processing in an example wherehardware having sufficient image processing capability is employed orthe like.

By way of example, a case where the instruction image is displayed onfirst LCD 12 and the camera image is displayed on second LCD 22 will bedescribed.

Referring to FIG. 14A, when right handedness is set, image data SIMGread from the memory is written in an area corresponding to layer LYR1-2with its orientation being maintained. In addition, the instructionimage data is also written in an area corresponding to layer LYR2-1 withits orientation being maintained. In this example, no data is written inareas corresponding to layers LYR1-1 and LYR2-2.

On the other hand, referring to FIG. 14B, when left handedness is set,image data SIMG read from the memory is written in the areacorresponding to layer LYR1-2 with its orientation being rotated by 180degrees. In addition, the instruction image data is also written in thearea corresponding to layer LYR2-1 with its orientation being rotated by180 degrees, as compared with the case where right handedness is set.

It is noted that a frame image (border) may be displayed around thecamera image. In that case, frame image data stored in advance in datamemory 34 for storage or the like is written in the area correspondingto layer LYR2-2. When left handedness is set, frame image data is alsowritten in the area corresponding to layer LYR2-2 with its orientationbeing rotated by 180 degrees as compared with the case where righthandedness is set.

FIG. 15 is a block diagram for providing image pick-up/displayprocessing in accordance with handedness according to the embodiment ofthe present invention.

Referring to FIG. 15, game device 100 includes, as its controlstructure, inner camera 23, a control unit 50, a buffer memory 54, acamera image display control unit 56, a mode setting unit 58, a positioninput portion 60, an instruction image generation unit 62, aninstruction image display control unit 64, a layered memory 68, andrendering units 70 and 72. Among these control blocks, buffer memory 54and layered memory 68 are provided by securing a prescribed area in mainmemory 32 (FIG. 3). Control unit 50, camera image display control unit56, mode setting unit 58, instruction image generation unit 62,instruction image display control unit 64, and rendering units 70 and 72are provided by execution of the program by CPU 31. In addition,position input portion 60 is mainly provided by touch panel 13 (FIG. 3).

Inner camera 23 includes image pick-up element 23A receiving light froma subject and a reading circuit 23B for reading image data in accordancewith an image obtained by light reception by image pick-up element 23Ain a prescribed order. Reading circuit 23B outputs image datarepresenting the image picked up by image pick-up element 23A. Here,reading circuit 23B reads the image data obtained by image pick-upelement 23A in accordance with the direction of reading indicated bycontrol unit 50. By switching between the directions of reading, theorientation of the image data output from reading circuit 23B can berotated by 180 degrees as necessary. The image data output from readingcircuit 23B is written in buffer memory 54. It is noted that aninstruction onto a prescribed position accepted by position inputportion 60 includes a user's touch operation or the like of a shutterbutton or the like displayed on first LCD 12.

Buffer memory 54 serves as a storage portion for temporarily storingimage data obtained by image pick-up element 23A and it is connected tocamera image display control unit 56 and memory control circuit 33

Camera image display control unit 56 causes at least one of first LCD 12and/or second LCD 22 to display the image data (camera image) obtainedby inner camera 23. More specifically, camera image display control unit56 writes image data stored in buffer memory 54 into a correspondinglayer within layered memory 68, in response to an instruction fromcontrol unit 50. Here, camera image display control unit 56 writes theimage data in an orientation indicated by control unit 50. By switchingbetween the orientations of writing, the orientation of the camera imagedisplayed on first LCD 12 and/or second LCD 22 can be rotated by 180degrees as necessary.

Control unit 50 outputs a capture instruction (shutter instruction) tomemory control circuit 33, in accordance with the instruction onto theprescribed position accepted by position input portion 60. Memorycontrol circuit 33 causes data memory 34 for storage, which is anon-volatile storage medium, to store image data having been stored inbuffer memory 54 as a file, in response to the capture instruction fromcontrol unit 50.

Instruction image generation unit 62 generates instruction image datafor accepting the user's input operation as the application proceeds andoutputs the instruction image data to instruction image display controlunit 64. Instruction image display control unit 64 causes first LCD 12to display the instruction image in a prescribed area thereof. Morespecifically, instruction image display control unit 64 writesinstruction image data generated by instruction image generation unit 62in a corresponding layer held in layered memory 68, in response to aninstruction from control unit 50. Here, instruction image displaycontrol unit 64 writes the instruction image data in the orientationindicated by control unit 50. By switching between the orientations ofwriting, the orientation of the instruction image displayed on first LCD12 can be rotated by 180 degrees as necessary.

Mode setting unit 58 sets any of a right handedness mode and a lefthandedness mode, in response to a user's instruction through positioninput portion 60 or the like. Control unit 50 is notified of the modeset by this mode setting unit 58.

In response to the instruction of a position on first LCD 12, positioninput portion 60 emits the instruction of that position to control unit50.

Control unit 50 controls, in a centralized manner, reading circuit 23B,camera image display control unit 56 and instruction image displaycontrol unit 64, in accordance with the mode set by mode setting unit58. In addition, control unit 50 provides an instruction in accordancewith the user's operation also to memory control circuit 33. Namely,when the left handedness mode is set, control unit 50 controls readingcircuit 23B such that camera image data is output in the orientationrotated by 180 degrees as compared with a case where the righthandedness mode is set and controls camera image display control unit 56such that the camera image data output from reading circuit 23B (thatis, the image data stored in buffer memory 54) is displayed in theorientation further rotated by 180 degrees. In addition, when the lefthandedness mode is set, control unit 50 controls instruction imagedisplay control unit 64 such that the instruction image is displayed inthe orientation rotated by 180 degrees as compared with the case wherethe right handedness mode is set.

<Processing for Registering Owner Identification Information>

Processing for registering owner identification information (state ST18)in the state transition diagram shown in FIG. 5 will now be described.

If owner identification information is not registered when “owner” image102 (FIG. 6) displayed on the title menu is touched with touch pen 27etc., processing for checking handedness of the owner described above isperformed and thereafter transition to the processing for registeringowner identification information (state ST18 in FIG. 5) is made. In thisprocessing for registering owner identification information, an initialvalue of the “brain age” of the owner, a face image (head shot orself-portrait) of the owner, a signature of the owner, a date of birthof the owner, and the like are registered.

Namely, owner_face image file 402, owner_signature image file 404 andowner_setting file 406 shown in FIG. 10 are created.

Overview of the processing for registering owner identificationinformation according to the present embodiment will be described withreference to FIG. 16. In step S2, CPU 31 executes the check game. Morespecifically, CPU 31 selects one check game or a plurality of checkgames among a plurality of check games prepared in advance and executesthe game(s). FIG. 19 shows one example of the check game. FIG. 19 showsa calculation game by way of example of the check game. Morespecifically, CPU 31 randomly reads image data representing questions(background data or object data) from data memory 34 for storage or thelike and causes second LCD 22 to successively display the image data. Inthe example shown in FIG. 19, such questions as “3×2=”, “2×9=” and“21+33=” are displayed in alignment in a vertical direction on secondLCD 22. When the user writes an answer to the question on first LCD 12by using touch pen 27 etc., CPU 31 causes first LCD 12 to display animage in accordance with a touch trail detected by touch panel 13. Atthe same time, CPU 31 performs character recognition processing on thetouch trail. In addition, CPU 31 checks a result of recognition againsta correct answer of the question, and when the answer matches with thecorrect answer, CPU 31 causes second LCD 22 to display a correct answermark “O” over the image representing the question. If the answer doesnot match with the correct answer, a correction input is accepted for aprescribed period of time. If the answer does not still match with thecorrect answer, transition to a next question is made. When transitionto the next question is made, CPU 31 provides such an effect that theentire image displayed on second LCD 22 moves upward in the screen, andrandomly reads image data representing a new question from data memory34 for storage. Then, a newly read question is displayed in a lowermostportion on second LCD 22.

Similar processing is thus performed for subsequent questions, and whenall questions are finished, the present calculation game ends. It isnoted that various games other than the calculation game described abovemay be executed a plurality of times as the check game. In addition, agame in which utterance of the user is obtained through microphone 43and subjected to voice recognition processing and a result ofrecognition is utilized may be included in the check game. In this case,selection as to whether a situation permits utterance of the user or notmay be accepted in advance. In addition, prior to start of the checkgame, explanation of the check game may be displayed in order to assista user's play operation.

Referring again to FIG. 16, in step S4, CPU 31 calculates an initialvalue of the “brain age” of the user (in this case, the owner) inaccordance with prescribed criteria, based on a time required for thecheck game and results (performance) such as the number of correctanswers/incorrect answers. In subsequent step S6, CPU 31 has thecalculated initial value of the “brain age” stored in association withthe owner. Namely, CPU 31 has the initial value of the “brain age”stored in owner_brain age data 410, together with the current timeinformation (data on time and day).

Regarding the timing of storage of the initial value of the “brain age”together with the current time information (data on time and day) inowner_brain age data 410, it may be stored simultaneously with display(step S20) of the obtained “brain age” of the owner which will bedescribed later.

In step S8, CPU 31 executes a face image obtaining sub routine to obtaina face image of the owner.

Here, the processing in the face image obtaining sub routine will bedescribed with reference to FIG. 17. It is noted that the face imageobtaining sub routine shown in FIG. 17 is executed also in changing thecontents in the already-registered owner identification information andin registering a guest face image which will be described later.

Initially, CPU 31 determines whether a situation permits image pick-upby the camera or not (step S100). More specifically, CPU 31 causes firstLCD 12 and second LCD 22 to display a notification image inviting theuser to make selection as to whether a situation permits image pick-upor not. FIG. 20 shows an exemplary screen displayed on first LCD 12 andsecond LCD 22 in step S100. In the screen shown in FIG. 20, anotification image 130 inviting the user to make selection as to whethera situation permits image pick-up or not as well as a “YES” image 132for accepting an instruction that the situation permits image pick-upand a “NO” image 134 for accepting an instruction that the situationdoes not permit image pick-up are displayed.

When “YES” image 132 is touched with touch pen 27 etc., CPU 31determines that the situation permits image pick-up by the camera (YESin step S100). Then, the process proceeds to step S102. On the otherhand, when “NO” image 134 is touched with touch pen 27 etc., CPU 31determines that the situation does not permit image pick-up by thecamera (NO in step S100). Then, the process proceeds to step S112.

Instead of the configuration as described above that whether thesituation permits image pick-up by the camera or not is determined basedon the user's operation, CPU 31 may automatically make suchdetermination. For example, a quantity of light received by the imagepick-up element may be detected and image pick-up may be prohibited whenthe quantity is equal to or lower than a prescribed value, or if animage pick-up device has a face recognition function, image pick-up maybe prohibited when a face cannot be recognized with that function.

In step S102, CPU 31 has a Live image obtained by inner camera 23displayed. In subsequent step S104, CPU 31 determines whether the userhas provided a capture instruction (shutter instruction) or not. FIG. 21shows an exemplary screen displayed on first LCD 12 and second LCD 22 insteps S102 and S104. In the screen shown in FIG. 21, a Live image 136obtained by inner camera 23 is displayed and a “ready” image 138 foraccepting the capture instruction is displayed.

When “ready” image 138 is touched with touch pen 27 etc., CPU 31determines that the capture instruction has been provided (YES in stepS104). Then, the process proceeds to step S106. On the other hand,unless “ready” image 138 is touched with touch pen 27 etc., CPU 31determines that the capture instruction has not been provided (NO instep S104). Therefore, the processing in steps S102 and S104 is repeateduntil “ready” image 138 is touched with touch pen 27 etc.

In step S106. CPU 31 notifies the user of timing of capture during aperiod from the time point when the capture instruction was provideduntil image data obtained by inner camera 23 is captured. FIG. 22 showsan exemplary screen displayed on first LCD 12 and second LCD 22 in stepS106. In the screen shown in FIG. 22, Live image 136 obtained by innercamera 23 is displayed and a notification image 140 showing a remainingtime until capture by inner camera 23 is displayed. It is noted thatdisplay contents in notification image 140 are updated over time todisplay “3”, “2” and “1” in accordance with the remaining time untilcapture. Such update is made in order to suppress occurrence of “camerashake” originating from the user's touch operation on touch panel 13.Namely, the user securely holds game device 100 in accordance withdisplayed notification image 140, so that occurrence of camera shake atthe timing of capture can be suppressed.

In subsequent step S108, CPU 31 has the captured camera image displayedto the user and determines with regard to the captured camera imagewhether photographing again is necessary or not (step S110). Morespecifically, CPU 31 causes first LCD 12 and second LCD 22 to display anotification image inviting the user to make selection as to whetherphotographing again is requested or not. FIG. 23 shows an exemplaryscreen displayed on first LCD 12 and second LCD 22 in steps S108 andS110. In the screen shown in FIG. 23, a head shot 142 captured by innercamera 23 is displayed as well as an “OK” image 144 for accepting aninstruction that photographing again is not necessary and a“photographing again” image 146 for accepting an instruction thatphotographing again is necessary are displayed.

When “OK” image 144 is touched with touch pen 27 etc., CPU 31 determinesthat photographing again is not required (NO in step S110). Then, theprocess proceeds to step S120. On the other hand, when “photographingagain” image 146 is touched with touch pen 27 etc., CPU 31 determinesthat photographing again is required (YES in step S110). Then, theprocess returns to step S102.

In contrast, in step S112, CPU 31 determines whether a self-portraitinstead of the head shot can be input or not. More specifically, CPU 31causes first LCD 12 and second LCD 22 to display a notification imageinviting the user to make selection as to whether a self-portrait can beinput or not. FIG. 24 shows an exemplary screen displayed on first LCD12 and second LCD 22 in step S112. In the screen shown in FIG. 24, anotification image 150 inviting the user to make selection as to whethera self-portrait can be input or not as well as a “YES” image 152 foraccepting an instruction that a self-portrait instead of the head shotcan be input and a “NO” image 154 for accepting an instruction that aself-portrait instead of the head shot cannot be input are displayed.

When “YES” image 152 is touched with touch pen 27 etc., CPU 31determines that a self-portrait instead of the head shot can be input(YES in step S112). Then, the process proceeds to step S114. On theother hand, when “NO” image 154 is touched with touch pen 27 etc., CPU31 determines that a self-portrait instead of the head shot cannot beinput (NO in step S112). Then, the process returns to step S100.

In step S114, CPU 31 has a screen for accepting an input of theself-portrait by the user displayed. More specifically, CPU 31 has ahand-drawing input screen for accepting a series of input operationsusing touch pen 27 etc. on touch panel 13 displayed. In subsequent stepS116, CPU 31 has a hand-drawn image (self-portrait) in accordance with atrail of a series of input operations (touch trail) displayed. Infurther subsequent step S118, CPU 31 determines whether a series ofinput operations ended or not.

FIG. 25 shows an exemplary screen displayed on first LCD 12 and secondLCD 22 in steps S114 to S118. In the screen shown in FIG. 25, anotification image 156 for inviting the user to input the self-portraitas well as a hand-drawing input area 158, an “undo” image 160 foraccepting an instruction to cancel input contents and an “enter” image162 for accepting an instruction to end a series of input operations aredisplayed When a self-portrait has already been registered, thatself-portrait may be displayed as an initial value in hand-drawing inputarea 158. When the user provides hand-drawing input on first LCD 12 withtouch pen 27 etc., CPU 31 causes first LCD 12 to display in real time animage (self-portrait) in accordance with the touch trail detected bytouch panel 13. It is noted that the image data detected by touch panel13 is successively written in a prescribed area in main memory 32. Theimage data written in main memory 32 is reset (erased) by selection of“undo” image 160. Alternatively, when “enter” image 162 is touched withtouch pen 27 etc., CPU 31 determines that a series of input operationsended (YES in step S118). Then, the process proceeds to step S120. Onthe other hand, unless “enter” image 162 is touched with touch pen 27etc., CPU 31 determines that a series of input operations continues (NOin step S118). Therefore, the processing in steps S116 and S118 isrepeated until “enter” image 162 is touched with touch pen 27 etc.

In step S120, CPU 31 determines whether the current mode is set to the“owner mode” or not. The present face image obtaining sub routine isexecuted in common also during the check game which will be describedlater. In the check game, in addition to the “owner mode” similar to theprocessing for registering owner identification information, a “guestmode” is prepared. Step S120 is a step for switching between thecontents in the processing, in accordance with the mode selected fromthese “owner mode” and “guest mode”. Since the “owner mode” is setwithout fail in the processing for registering owner identificationinformation, determination as “YES” is made in step S120.

When the current mode is set to the owner mode (YES in step S120), theprocess proceeds to step S122. On the other hand, when the current modeis set to the guest mode (NO in step S120), the process proceeds to stepS130.

In step S122, whether a face image has already been registered as theowner identification information or not is determined. Namely, CPU 31determines whether owner_face image file 402 (FIG. 10) storing some kinddata is present or not.

When the face image has not yet been registered as the owneridentification information (NO in step S122), CPU 31 creates owner_faceimage file 402 from the face image (head shot or self-portrait) obtainedin the preceding step (step S124). Then, the process returns. On theother hand, when the face image has already been registered as the owneridentification information (YES in step S122), CPU 31 overwritesalready-created owner_face image file 402 with the face image (head shotor self-portrait) obtained in the preceding step (step S126). Then, theprocess returns.

On the other hand, in step S130, CPU 31 determines whether there is anempty space in guest_face image file 442 (FIG. 10) or not. Namely, CPU31 determines whether or not there is an area remaining for storing aface image (head shot or self-portrait) obtained in the preceding step.When there is an empty space in guest_face image file 442 (YES in stepS130), the process proceeds to step S132. On the other hand, when thereis no empty space in guest_face image file 442 (NO in step S130), theprocess proceeds to step S134.

In step S132, guest_face image file 442 is created from the face image(head shot or self-portrait) obtained in the preceding step. Then, theprocess returns.

In step S134, CPU 31 has already-stored guest_face image files 442displayed in a list. Namely, CPU 31 invites the user to selectguest_face image file 442 to be erased. In subsequent step S136, CPU 31determines whether the face image obtained in the present processing hasbeen selected or not. When the face image obtained in the presentprocessing has been selected (YES in step S136), the process returns.Namely, the face image obtained in the present face image obtaining subroutine is not stored but discarded. On the other hand, when the faceimage obtained in the present processing has not been selected (NO instep S136), the process proceeds to step S138.

In step S138, CPU 31 overwrites selected guest_face image file 442 withthe face image (head shot or self-portrait) obtained in the precedingstep. Then, the process returns.

Thus, by executing the program according to the present embodiment, CPU31 provides a selection function for accepting, when result data in theguest mode (second mode) has already been stored in association with allprepared accounts of unspecified users and when a new guest mode is setand the interactive application is executed, selection of data to beerased from among already-stored result data in the guest mode andsecond result data in the guest mode obtained as a result of most recentexecution of the interactive application, and an erasing function forerasing the result data in the guest mode selected by the selectionfunction.

Though such a configuration that the user is caused to select guest_faceimage file 442 to be erased in step S134 when there is no empty space inguest_face image file 442 has been illustrated, oldest guest_face imagefile 442 may automatically be erased when there is no empty space inguest_face image file 442.

Referring again to FIG. 16, in subsequent step S10, CPU 31 executes asignature image obtaining sub routine to obtain a signature image of theowner.

Referring to FIG. 18, initially, CPU 31 has a screen for accepting aninput of a signature image by the user displayed (step S150). Morespecifically, CPU 31 has a handwriting input screen for accepting aseries of input operations with touch pen 27 etc. on touch panel 13displayed. In subsequent step S152, CPU 31 has a hand-drawn image(signature image) in accordance with a trail of a series of inputoperations (touch trail) displayed. In further subsequent step S154, CPU31 determines whether a series of input operations ended or not.

FIG. 26 shows an exemplary screen displayed on first LCD 12 and secondLCD 22 in steps S150 to S154. In the screen shown in FIG. 26, anotification image 170 for inviting the user to input a signature aswell as a handwriting input area 164, an “undo” image 166 for acceptingan instruction to cancel input contents and an “enter” image 168 foraccepting an instruction to end a series of input operations aredisplayed. When a signature image has already been registered, thatregistered signature image may be displayed in a handwriting displayarea 172. When the user provides handwriting input on first LCD 12 withtouch pen 27 etc., CPU 31 causes first LCD 12 to display in real time ahand-drawn image (signature image) in accordance with the touch traildetected by touch panel 13. It is noted that the hand-drawn imagedetected by touch panel 13 is successively written in a prescribed areain main memory 32. The image data written in main memory 32 is reset(erased) by selection of “undo” image 166. In addition, when “enter”image 168 is touched with touch pen 27 etc., CPU 31 determines that aseries of input operations ended (YES in step S154). Then, the processproceeds to step S156. On the other hand, unless “enter” image 168 istouched with touch pen 27 etc., CPU 31 determines that a series of inputoperations continues (NO in step S154). Therefore, the processing insteps S152 and S154 is repeated until “enter” image 168 is touched withtouch pen 27 etc.

In step S156, whether the signature image has already been registered asthe owner identification information or not is determined. Namely, CPU31 determines whether owner_signature image file 404 (FIG. 10) storingsome kind data is present or not. When the signature image has not yetbeen registered as the owner identification information (NO in stepS156), CPU 31 creates owner_signature image file 404 from the signatureimage obtained in step S152 (step S158). Then, the process returns. Onthe other hand, when the signature image has already been registered asthe owner identification information (YES in step S156), CPU 31overwrites already-created owner_signature image file 404 with thesignature image obtained in step S152 (step S160). Then, the processreturns.

Referring again to FIG. 16, in step S12, CPU 31 has a screen foraccepting user's input of a date of birth displayed. In subsequent stepS14, CPU 31 performs character recognition processing on the trail inputby the user with touch pen 27 etc. In further subsequent step S16, CPU31 has a result of recognition displayed as the date of birth of theowner. In further subsequent step S18, CPU 31 determines whethercorrection of the input contents as a whole is requested or not.

FIG. 27 shows an exemplary screen displayed on first LCD 12 and second.LCD 22 in steps S12 to S18. In the screen shown in FIG. 27, anotification image 184 inviting the user to input whether the inputcontents as a whole should be corrected or not as well as a face image176 and a signature image 174 that have previously been obtained, adate-of-birth input area 178, a “correction” image 180 for accepting aninstruction for correcting the input contents as a whole, and an “enter”image 182 for accepting approval of the input contents as a whole aredisplayed. When the user provides a handwriting input on a positioncorresponding to date-of-birth input area 178 on first LCD 12 with touchpen 27 etc., CPU 31 has a result of recognition of the trail detected bytouch panel 13 displayed in a corresponding area (“year”, “month” and“day”). In addition, when “correction” image 180 is touched with touchpen 27 etc., CPU 31 determines that correction of the input contents asa whole is requested (YES in step S18). Then, the process returns tostep S8. On the other hand, when “enter” image 182 is touched with touchpen 27 etc., CPU 31 determines that correction of the input contents asa whole is not requested (NO in step S18). Then, CPU 31 createsowner_setting file 406 (FIG. 10). Thereafter, the process proceeds tostep S20.

In step S20, CPU 31 has the “brain age” of the owner obtained in step S4displayed. Here, the face image of the owner which represents otherowner identification information is also displayed. The processing forregistering the owner identification information thus ends.

<Training Game>

A training game in the owner mode (state ST6) and a training game in theguest mode (state ST24) in the state transition diagram shown in FIG. 5will now be described.

When “training” image 210 is touched with touch pen 27 etc. in the mainmenu for the owner shown in FIG. 8, first LCD 12 and second LCD 22display a menu of the training game shown in FIG. 28 (owner mode). Then,the training game in the owner mode is started. Alternatively, when“training” image 310 is touched with touch pen 27 etc. in the main menufor the guest shown in FIG. 9, first LCD 12 and second LCD 22 display amenu of the training game shown in FIG. 29 (guest mode). Then, thetraining game in the guest mode is started.

In the menu of the training game in the owner mode shown in FIG. 28,signature image 202 of the owner, face image 204 of the owner, image 206indicating a “brain age” value of the owner, and “stamp” acquisitionstate 208 of the owner are displayed, as in the main menu for the ownershown in FIG. 8. In addition, in this menu, instruction images 220showing training games that can be played by the owner are displayed ina list. Here, play of some of a plurality of training games (scenarios)that can be played by the owner is permitted in accordance with “stamp”acquisition state 208 indicating the result of the training game.Namely, as the owner plays a larger number of training games, the numberof types of training games that can be played by the user increases.

On the other hand, in the menu of the training game in the guest modeshown in FIG. 29, a notification image 320 inviting the user to select atraining menu is displayed, and instruction images 220 showing traininggames that can be played by a guest are displayed in a list. Here, thetypes of training games that can be played by the guest are set equallyto the types of training games that can be played by the owner shown inFIG. 28. Therefore, as the number of “stamps” acquired by the owner islarger, the number of types of training games that can be played by theguest also increases. It is noted that records of play of the traininggame by the guest are not reflected in the owner's “stamp”. Namely, theresults (records) of play of the training game by the owner are storedin association with the owner, whereas the results (records) of play ofthe training game by the guest are not stored.

Typical examples of the training games prepared in the applicationaccording to the present embodiment include the calculation game shownin FIG. 19 and the like. Other than such a calculation game, variousinteractive training games such as a memorization game or a spellinggame are prepared.

Thus, by executing the program according to the present embodiment, CPU31 functions as updating means for updating history information inaccordance with records of user's play of the interactive applicationwhile the owner mode (first mode) is set and determination means fordetermining a scenario permitted to proceed in the owner mode (firstmode) and the guest mode (second mode) from a plurality of scenariosbased on the history information. In the present embodiment, such aconfiguration that a type of a game representing an element in the gamecan be played by the user in accordance with a user's play status (suchas the number of times of play, the time for play, performance of play,and the like) has been illustrated. In addition to such a configuration,a configuration may be such that a character or an item that can be usedas an element in the game can be used by the user in accordance with theuser's play status.

A procedure for processing the training game according to the presentembodiment will be described hereinafter with reference to FIG. 30. Itis noted that the processing procedure shown in FIG. 30 is performedwhen “training” image 210 is selected in the main menu for the ownershown in FIG. 8 or when “training” image 310 is selected in the mainmenu for the guest shown in FIG. 9.

Referring to FIG. 30, initially, in step S50, CPU 31 determines type(s)of training game(s) that can be played, by referring to owner_trainingperformance data 420 (FIG. 10). In subsequent step S52, CPU 31 reads theinstruction image(s) corresponding to determined training game(s) thatcan be played from data memory 34 for storage and causes first LCD 12 todisplay the instruction image.

In subsequent step S54, CPU 31 determines whether any of the displayedinstruction images has been touched with touch pen 27 etc. or not. Whennone of the displayed instruction images has been touched (NO in stepS54), the processing in step S54 is repeated. On the other hand, whenany of the displayed instruction images has been touched (YES in stepS54), the process proceeds to step S56.

In step S56, CPU 31 specifies the selected training game. In furthersubsequent step S58, CPU 31 determines whether the current mode is setto the “owner mode” or not. When the current mode is set to the ownermode (YES in step S58), the process proceeds to step S60. On the otherhand, when the current mode is set to the guest mode (NO in step S58),the process proceeds to step S64.

In step S60, CPU 31 obtains the time required for previous play byreferring to owner_training time data 422 (FIG. 10) corresponding toeach selected training game and by summing up the total time requiredfor play of each training stored in owner_training time data 422. Ifowner_training performance data 420 relating to the selected traininggame is not yet present, a given default value is set as the timerequired for previous play. In subsequent step S62, CPU 31 has a screenfor accepting start of the selected training game displayed. On thisscreen, the time required for previous play that was obtained in stepS60 is displayed as the expected required time for play of the training.Then, the process proceeds to step S68.

On the other hand, in step S64, CPU 31 has a screen explaining contentsor the like of the selected training game displayed. In subsequent stepS66, CPU 31 has a screen for accepting start of the selected traininggame displayed. On this screen, a given default value is displayed asthe expected required time for play of the training. Then, the processproceeds to step S68.

In step S68, CPU 31 determines whether the user has indicated start ofthe training game or not. Namely, CPU 31 determines whether thedisplayed instruction image for accepting input of start has beentouched with touch pen 27 etc. or not. When the user indicated start ofthe training game (YES in step S68), the process proceeds to step S70.When the user has not indicated start of the training game (NO in stepS68), the processing in step S68 is repeated.

In step S70, CPU 31 executes the selected training game. In subsequentstep S72, CPU 31 has a result obtained by execution of the training game(the time required for play or the number of correct answers/incorrectanswers) displayed. In further subsequent step S74, CPU 31 determineswhether the current mode is set to the “owner mode” or not. When thecurrent mode is set to the owner mode (YES in step S74), the processproceeds to step S76. On the other hand, when the current mode is set tothe guest mode (NO in step S74), the present training game ends.

In step S76, CPU 31 updates the contents in owner_training performancedata 420 and owner_training time data 422 corresponding to the executedtraining game, based on the results obtained by execution of thetraining game. In subsequent step S78, CPU 31 has a “stamp” acquisitionstate displayed, based on the contents in updated owner_trainingperformance data 420. Thereafter, the present training game ends.

<Check Game>

A check game (state ST12) and result output (state ST14) in the ownermode as well as a check game (state ST32), guest identificationinformation registration (face image) (state ST34) and result output(state ST36) in the guest mode in the state transition diagram shown inFIG. 5 will now be described.

A procedure for processing the check game according to the presentembodiment will be described with reference to FIGS. 31A and 31B.

The processing procedure shown in FIGS. 31A and 31B is performed when“brain age check” image 214 is selected in the main menu for the ownershown in FIG. 8 or when “brain age check” image 314 is selected in themain menu for the guest shown in FIG. 9.

Referring to FIG. 31A, initially, in step S200, CPU 31 determineswhether a situation permits utterance of the user or not. Thisdetermination is made in order to determine whether a game in whichutterance of the user is obtained through microphone 43 and subjected tovoice recognition processing and the result of recognition is utilizedcan be executed or not. More specifically, CPU 31 causes first LCD 12and second LCD 22 to display an image inviting the user to makeselection as to whether a situation permits utterance of the user ornot.

In subsequent step S202, CPU 31 selects a check game to be executed fromamong a plurality of check games prepared in advance, in accordance withthe result of determination in step S200. Check games substantially thesame as the training games described above are employed as the checkgames prepared in the application according to the present embodiment.Therefore, the check game according to the present embodiment includesthe calculation game as shown in FIG. 19 and the like. Other than such acalculation game, various interactive check games such as a memorizationgame or a spelling game are prepared. Preferably, a plurality of checkgames are selected, however, a single check game may be selected. Then,the process proceeds to step S204.

In step S204, CPU 31 has an expected required time for play of the wholecheck games) displayed, based on a given default value, in accordancewith the type of the selected check game(s). If time data of previousplay is present, that time may be displayed. In subsequent step S206,CPU 31 determines whether the current mode is set to the “owner mode” ornot. When the current mode is set to the owner mode (YES in step S206),the process proceeds to step S208. On the other hand, when the currentmode is set to the guest mode (NO in step S206), the process proceeds tostep S212.

In step S208, CPU 31 obtains the time required for previous play of theselected check game, by referring to owner_training time data 422 (FIG.10) corresponding to the selected check game. If owner_training timedata 422 relating to the selected check game is not yet present, a givendefault value is set as the time required for previous play. Insubsequent step S210, CPU 31 has a screen for accepting start of thecheck game displayed. On this screen, the time required for previousplay that was obtained in step S208 is displayed as the expectedrequired time for play of the check game.

FIG. 32 shows an exemplary screen displayed on first LCD 12 and secondLCD 22 in step S210. In the screen shown in FIG. 32, a notificationimage 230 notifying the user that the check game can be started and atime 234 required for previous play that was obtained in step S208 aredisplayed. In the screen shown in FIG. 32, a “start brain age check”image 232 for accepting start of the check game is further displayed.When “start brain age check” image 232 is touched with touch pen 27etc., the process proceeds to step S216.

Referring again to FIG. 31A, in step S212, CPU 31 has an expectedrequired time for play of the selected individual check game (a givendefault value) displayed. In further subsequent step S214, CPU 31 has ascreen for accepting start of the selected check game displayed. On thisscreen, the required time obtained in step S212 is displayed. Prior todisplay of the expected required time for play of the selectedindividual check game, explanation of the check game may be displayed inorder to assist the user's play operation.

FIG. 33 shows an exemplary screen displayed on first LCD 12 and secondLCD 22 in step S214. In the screen shown in FIG. 33, an image 330 fornotifying the user that the check game can be started and an expectedrequired time 334 for play obtained in step S212 are displayed. On thescreen shown in FIG. 33, a “start brain age check” image 332 foraccepting start of the check game is further displayed. When “startbrain age check” image 332 is touched with touch pen 27 etc., theprocess proceeds to step S216.

Referring again to FIGS. 31A and 31B, in step S216, CPU 31 executes theselected check game. In subsequent step S218, CPU 31 determines whetherall check games selected in step S202 have been executed or not. Whenthere is an unexecuted check game remaining among the selected checkgames (NO in step S218), the processing in steps S206 to S216 isrepeated. On the other hand, when the selected check games have all beenexecuted (YES in step S218), the process proceeds to step S220.

In step S220, CPU 31 calculates the user's “brain age” in accordancewith prescribed criteria, based on the results (performance) such as thetime required for the check game or the number of correctanswers/incorrect answers. In subsequent step S222, CPU 31 determineswhether the current mode is set to the owner mode or not. When thecurrent mode is set to the owner mode (YES in step S222), the processproceeds to step S224. On the other hand, when the current mode is setto the guest mode (NO in step S222), the process proceeds to step S240.

In step S224, CPU 31 has the calculated “brain age” stored inassociation with the owner. Namely, CPU 31 writes the calculated “brainage” value in owner_brain age data 410 (FIG. 10), together with the timeinformation. The “brain age” values for N days can be stored inowner_brain age data 410, and when a “brain age” value is additionallystored, the oldest “brain age” value is erased. In subsequent step S226,CPU 31 has an image indicating the calculated “brain age” valuedisplayed. In further subsequent step S228, CPU 31 has an imageindicating history of the “brain age” values of the owner displayed, byreferring to owner_brain age data 410. More specifically, CPU 31 haschange over time of the “brain age” of the owner displayed in a graph.

FIG. 34 shows an exemplary screen displayed on first LCD 12 and secondLCD 22 in step S228. In the screen shown in FIG. 34, an image 250displaying in a graph change over time of the “brain age” of the owneris displayed. Thereafter, the process proceeds to step S230.

Referring again to FIG. 31B, in step S230, CPU 31 determines whetheralready-stored guest_brain age file 444 is present or not. Whenalready-stored guest_brain age file 444 is present (YES in step S230),the process proceeds to step S232. On the other hand, whenalready-stored guest_brain age data is not present (NO in step S230),the process proceeds to step S234.

In step S232, CPU 31 causes display of the calculated “brain age” valueof the present owner and the already-stored “brain age” value of theguest in a comparable manner. FIG. 35 shows an exemplary screendisplayed on first LCD 12 and second LCD 22 in step S232. In the screenshown in FIG. 35, a “brain age” value 244 calculated for the presentowner is displayed in correspondence with a face image 242 of the ownerand an already-stored “brain age” value 248 of a guest is displayed incorrespondence with a face image 246 of the guest, Namely, the “brainage” value and the face image are displayed as one group. Thus,comparison of the results of play of the same check game between theowner and the guest is displayed on the same screen. Then, the processproceeds to step S236.

Though FIG. 35 shows an example where comparison between the “brain age”values of the owner and one guest is displayed, if “brain ages” of alarger number of guests have already been stored, images are arrangedmore efficiently. For example, the number of persons whose “brain age”values (including the present play results) have already been stored isequal to or smaller than four including the owner and the guest(s), thevalues for two persons are arranged in a laterally aligned manner oneach of first LCD 12 and second LCD 22. In contrast, when the number ofpersons whose “brain age” values have already been stored exceeds fourincluding the owner and the guests, values for four persons are alignedand arranged in two rows and two columns on each of first LCD 12 andsecond LCD 22.

Thus, by executing the program according to the present embodiment, CPU31 provides a third display control function for displaying result datain the owner mode (first mode) together with result data in the guestmode (second mode).

Referring again to FIG. 31B, in step S234, CPU 31 has a screen invitingalso a guest, in addition to the owner, to play the check gamedisplayed. For example, such a message that “let's have someone arounddo this” is displayed. Then, the process proceeds to step S236.

In step S236, CPU 31 has the “stamp” acquisition state of the ownerdisplayed, in correspondence with the owner identification informationsuch as the signature of the owner, the face image of the owner, and the“brain age” value of the owner. Then, the check game ends.

On the other hand, in step S240, CPU 31 executes the face imageobtaining sub routine shown in FIG. 17 to obtain the face image of theguest. This is done in order to store the “brain age” value inassociation with the guest who actually played the check game. Insubsequent step S242, CPU 31 has the calculated “brain age” stored inassociation with the guest. Namely, CPU 31 writes the calculated “brainage” value in guest brain age file 444 associated with guest_face imagefile 442 created or updated in the face image obtaining sub routine thathas precedently been executed. In further subsequent step S244, CPU 31determines whether two or more “brain age” values in total (includingthe present play result) of the owner and the guest(s) have already beenstored or not, by referring to owner_brain age data 410 and guest_brainage file 444.

When the number of already-stored “brain age” values is less than two(NO in step S244), the check game ends. On the other hand, when two ormore “brain age” values in total have already been stored (YES in stepS244), the process proceeds to step S246.

In step S246, CPU 31 causes display of the calculated “brain age” valueof the present guest and the already-stored “brain age” value of theowner or the guest(s) in a comparable manner. An exemplary screen forcomparison and display is as shown in FIG. 35 above. Then, the checkgame ends.

<Association Game>

An association game (state ST8) and result output (state ST10) in theowner mode as well as an association game (state ST26), guestidentification information registration (signature) (state ST28) andresult output (state ST30) in the guest mode in the state transitiondiagram shown in FIG. 5 will now be described.

The association game according to the present embodiment refers to agame in which a “photograph” or “voice and sound” associated with a wordpresented as a “theme” is collected or a “picture” is hand-drawn.Namely, when some kind of “theme” is presented, the user takes a“photograph” that the user considers as most suitable for that “theme”by using inner camera 23 or outer camera 25. Alternatively, the usercollects “voice and sound” that the user considers as most suitable forthat “theme” by using microphone 43. Alternatively, the user hand-drawsa “picture” that the user considers as most suitable for that “theme” byusing touch pen 27 etc. Thereafter, among a plurality of users includingthe owner and the guest(s), works of the users are displayed in a list.It is assumed that which kind of input among a “photograph”, “voice andsound” and a “picture” is requested is predetermined in accordance witha “theme”.

A procedure for processing the association game according to the presentembodiment will be described hereinafter with reference to FIGS. 36A,36B, 37A, and 37B.

It is noted that the processing procedure shown in FIGS. 36A and 36B isperformed when “theme” image 212 is selected in the main menu for theowner shown in FIG. 8. Alternatively, the processing procedure shown inFIGS. 37A and 37B is performed when “theme” image 312 is selected in themain menu for the guest shown in FIG. 9.

(1. Association Game in Owner Mode)

Referring to FIGS. 36A and 36B, initially, in step S300, CPU 31 has“themes” prepared in advance displayed in a list. More specifically, CPU31 reads instruction images corresponding to respective “themes”prepared in advance from data memory 34 for storage and causes first LCD12 to display the instruction images. It is noted that the “themes” maybe displayed in a stepwise fashion. Namely, a list of a plurality ofcategories may initially be displayed, and when any category isselected, “themes” included in the selected category may be displayed ina list. In subsequent step S302, CPU 31 determines whether selectionfrom among the “themes” displayed in a list have been made or not.

FIG. 38 shows an exemplary screen displayed on first LCD 12 and secondLCD 22 in steps S300 and S302. In the screen shown in FIG. 38, anotification image 260 inviting the user to select a “theme” isdisplayed as well as instruction images 262 indicating selectable“themes” are displayed in a list. It is noted that the selectable themesare common between the owner mode and the guest mode. When any ofinstruction images 262 indicating the “themes” displayed in a list istouched with touch pen 27 etc., CPU 31 determines that a “theme” hasbeen selected (YES in step S302). Then, in subsequent step S304, CPU 31specifies the selected “theme”. Further, the process proceeds to stepS306. On the other hand, when none of instruction images 262 indicatingthe “themes” displayed in a list is touched, CPU 31 determines that the“theme” has not been selected (NO in step S302) The processing in stepS302 is repeated.

In step S306, CPU 31 determines, with regard to the selected “theme”,whether a theme file has already been registered or not. Namely, CPU 31determines whether owner_theme file 430 corresponding to the selected“theme” has already been created or not. When the theme file has alreadybeen registered (YES in step S306), the process proceeds to step S308.On the other hand, when the theme file has not yet been registered (NOin step S306), the process proceeds to step S310.

In step S308, CPU 31 determines, with regard to the selected “theme”,whether erase of the already-registered theme file is permitted or not.More specifically, CPU 31 causes first LCD 12 and second LCD 22 todisplay an image inviting the user to make selection as to whether thealready-registered theme file may be erased or not. With regard to theselected “theme”, when erase of the already-registered theme file is notpermitted (NO in step S308), the process returns to step S300. On theother hand, with regard to the selected “theme”, when erase of thealready-registered theme file is permitted (YES in step S308), theprocess proceeds to step S310.

In step S310, CPU 31 determines a type of input requested in regard tothe selected “theme”. When the selected “theme” requests a “photograph”(“photograph” in step S310), the process proceeds to step S320.Alternatively, when the selected “theme” requests a hand-drawn “picture”(“hand-drawing” in step S310), the process proceeds to step S340.Alternatively, when the selected “theme” requests “voice and sound”(“voice and sound” in step S310), the process proceeds to step S360.

In step S320, CPU 31 determines whether a situation permits imagepick-up by the camera or not. More specifically, CPU 31 causes first LCD12 and second LCD 22 to display an image inviting the user to makeselection as to whether a situation permits image pick-up or not. When asituation permits image pick-up by the camera (YES in step S320), theprocess proceeds to step S322. On the other hand, when a situation doesnot permit image pick-up by the camera (NO in step S320), the processreturns to step S300.

In step S322, CPU 31 has a Live image obtained by inner camera 23 orouter camera 25 displayed, together with the selected “theme”. Insubsequent step S324, CPU 31 determines whether the user has provided acapture instruction (shutter command) or not. When the captureinstruction has been provided (YES in step S324), the process proceedsto step S326. On the other hand, when the capture instruction has notbeen provided (NO in step S324), the processing in steps S322 and S324is repeated.

In step S326, CPU 31 captures image data obtained by inner camera 23 orouter camera 25. In subsequent step S328, CPU 31 has the captured cameraimage displayed to the user. In further subsequent step S330, CPU 31determines, with regard to the captured camera image, whetherphotographing again is required or not. More specifically, CPU 31 causesfirst LCD 12 and second LCD 22 to display an image inviting the user tomake selection as to whether photographing again is necessary or not.When photographing again with regard to the captured camera image isrequired (YES in step S330), the process returns to step S322. On theother hand, when photographing again with regard to the captured cameraimage is not required (NO in step S330), the process proceeds to stepS380.

In step S340, CPU 31 has a screen for accepting user's hand-drawinginput displayed, together with the selected “theme”. In subsequent stepS342, CPU 31 has an image in accordance with a trail of a series ofinput operations (touch trail) (hand-drawn picture) displayed. Infurther subsequent step S344, CPU 31 determines whether a series ofinput operations ended or not.

FIG. 39 shows an exemplary screen displayed on first LCD 12 and secondLCD 22 in steps S340 to S344. In the screen shown in FIG. 39, an image270 showing the “theme” as well as a hand-drawing input area 272 aredisplayed. In the screen shown in FIG. 39, an “enter” image 274indicating end of a series of input operations is displayed. When theuser provides hand-drawing input on first LCD 12 with touch pen 27 etc.,CPU 31 has an image in accordance with the touch trail detected by touchpanel 13 (hand-drawn picture) displayed in real time in hand-drawinginput area 272. It is noted that the image data detected by touch panel13 is successively written in a prescribed area of main memory 32.Thereafter, when “enter” image 274 is touched with touch pen 27 etc.,CPU 31 determines that a series of input operations ended (YES in stepS344). Then, the process proceeds to step S380. On the other hand,unless “enter” image 274 is touched with touch pen 27 etc., CPU 31determines that a series of input operations continues (NO in stepS344). Therefore, the processing in step S342 is repeated until “enter”image 274 is touched with touch pen 27 etc.

Referring again to FIGS. 36A and 36B, in step S360, CPU 31 determineswhether a situation permits recording with the microphone or not. Morespecifically, CPU 31 causes first LCD 12 and second LCD 22 to display animage inviting the user to make selection as to whether a situationpermits recording or not. When a situation permits recording with themicrophone (YES in step S360), the process proceeds to step S362. On theother hand, when a situation does not permit recording with microphone(NO in step S360), the process returns to step S300.

In step S362, CPU 31 has an image for accepting an instruction to startrecording displayed, together with the selected “theme”. In subsequentstep S364, CPU 31 determines whether the user has provided aninstruction to start recording or not. When the instruction to startrecording has been provided (YES in step S364), the process proceeds tostep S366. On the other hand, when the instruction to start recordinghas not been provided (NO in step S364), the processing in step S364 isrepeated.

In step S366, CPU 31 causes voice and sound collected by microphone 43stored for a prescribed period of time. In subsequent step S368, CPU 31reproduces recorded audio data and causes speaker 45 to output recordedvoice and sound. In subsequent step S370, CPU 31 determines whetherreproduction of the recorded voice and sound again is requested or not.More specifically, CPU 31 causes first LCD 12 and second LCD 22 todisplay an image inviting the user to make selection as to whether it isnecessary to reproduce again the recorded voice and sound or not. Whenthe reproduction of the recorded voice and sound again is required (YESin step S370), the process returns to step S368. On the other hand, whenthe reproduction of the recorded voice and sound again is not required(NO in step S370), the process proceeds to step S372.

In step S372, CPU 31 determines whether recording of voice and soundagain with regard to the recorded voice and sound is requested or not.More specifically, CPU 31 causes first LCD 12 and second LCD 22 todisplay an image inviting the user to make selection as to whether it isnecessary to record voice and sound again or not. With regard to therecorded voice and sound, when recording of voice and sound again isrequired (YES in step S372), the process returns to step S364. On theother hand, with regard to the recorded voice and sound, when recordingof voice and sound again is not requested (NO in step S372), the processproceeds to step S380.

In step S380, CPU 31 newly creates owner_theme file 430 from theobtained image data (photograph or hand-drawn picture) or the audio data(or overwrites already-created owner_theme file 430 therewith). Insubsequent step S382, contents in newly created or updated owner_themefile 430 are displayed or reproduced.

In further subsequent step S384, CPU 31 determines, with regard to thesame “theme”, whether already-stored guest_theme file 454 is present ornot. When already-stored guest_theme file 454 is present (YES in stepS384), the process proceeds to step S386. On the other hand, whenalready-stored guest_theme file 454 is not present (NO in step S384),the process proceeds to step S388.

In step S386, CPU 31 compares owner_theme file 430 created by thepresent owner with already-stored guest_theme file 454 for display. FIG.40 shows an exemplary screen displayed on first LCD 12 and second LCD 22in step S384. FIG. 40 shows an example where contents in owner_themefile 430 represent a “hand-drawn picture.” FIG. 40 is also applicable tovoice and sound and a photograph. In the screen shown in FIG. 40, animage 282 included in owner_file 430 created by the owner is displayedin correspondence with an image 284 included in owner_signature imagefile 452 and an image 286 included in guest_theme file 454 generated bya certain guest is displayed in correspondence with an image 288included in guest_signature image file 452 of that guest. Here,regarding the contents in the theme file created in present play of theassociation game, an “addition” image 290 indicating new addition isdisplayed in a superimposed manner. Thus, results of play of the sameassociation game by the owner and the guest(s) are compared anddisplayed on the same screen. Then, the processing for the associationgame ends.

Referring again to FIG. 36B, in step S388, CPU 31 has a screen forinviting also a guest, in addition to the owner, to play the associationgame displayed. FIG. 41 shows an exemplary screen displayed on first LCD12 and second LCD 22 in step S388. In the screen shown in FIG. 41,instruction images 262 indicating selectable “themes” are displayed in alist as well as a notification image 292 inviting also the guest to playthe association game is displayed. Then, the processing for theassociation game ends.

(2. Association Game in Guest Mode)

Processing for the association game in the guest mode will now bedescribed with reference to FIGS. 37A and 37B. It is noted that thesteps included in the flowchart shown in FIGS. 37A and 37B the same asin FIGS. 36A and 36B have the same reference characters allotted anddescription thereof will not be repeated.

Referring to FIGS. 37A and 37B, initially, in step S300, CPU 31 causes“themes” prepared in advance displayed in a list. More specifically, CPU31 reads an instruction image corresponding to each of the “themes”prepared in advance from data memory 34 for storage and causes first LCD12 to display the instruction image. In subsequent step S302, CPU 31determines whether selection from among the “themes” displayed in a listhas been made or not. When a “theme” has been selected (YES in stepS302), the process proceeds to step S304. On the other hand, when a“theme” has not been selected (NO in step S302), the processing in stepS302 is repeated.

In step S304, CPU 31 specifies the selected “theme”. In subsequent stepS310, CPU 31 determines a form of input requested for the selected“theme”.

When the selected “theme” requests a “photograph” (“photograph” in stepS310), processing the same as in steps S320 to S330 shown in FIG. 36A isperformed. Then, the process proceeds to step S381.

Alternatively, when the selected “theme” requests a hand-drawn “picture”(“hand-drawing” in step S310), processing the same as in steps S340 toS344 shown in FIG. 36A is performed. Then, the process proceeds to stepS381.

Alternatively, when the selected “theme” requests “voice and sound”(“voice and sound” in step S310), processing the same as in steps S360to S372 shown in FIG. 36A is performed. Then, the process proceeds tostep S381.

In step S381, CPU 31 executes the signature image obtaining sub routineas in FIG. 18 to obtain the signature image of the guest. In subsequentstep S383, CPU 31 has the image data (photograph or hand-drawn picture)or the audio data created in the present association game displayed, incorrespondence with the input signature of the guest. Thereafter, theprocess proceeds to step S390.

In step S390, CPU 31 determines whether there is an empty space inguest_face image file 442 or not. Namely, CPU 31 determines whether anarea for storing the image data (photograph or hand-drawn picture) orthe audio data created in the present association game is present ornot. When there is an empty space in “face image file 442” (YES in stepS390), the process proceeds to step S392. On the other hand, when thereis no empty space in guest_face image file 442 (NO in step S390), theprocess proceeds to step S394.

In step S392, CPU 31 creates guest_theme file 454 from the image data(photograph or hand-drawn picture) or the audio data created in thepresent association game and creates a guest_signature file from theinput signature image of the guest. Then, the process proceeds to stepS385.

In step S394, CPU 31 has signature images included in guest_signatureimage file 452 associated with already-stored guest_theme file 454displayed in a list. Namely, CPU 31 invites the user to selectguest_theme file 454 to be erased.

FIGS. 42 and 43 show an exemplary screen displayed on first LCD 12 andsecond LCD 22 in step S394. It is noted that FIGS. 42 and 43 illustratean example where the guest theme file includes a “hand-drawn picture.”FIGS. 42 and 43 are also applicable to voice and sound and a photograph.In the screen shown in FIG. 42, a notification image 338 inviting theuser to select guest_theme file 454 to be erased is displayed as well assignature images 336 included in guest_signature image file 452associated with selectable guest_theme file 454 are displayed in a list.When any of signature images 336 displayed in a list is touched withtouch pen 27 etc., an image 342 included in guest_theme file 454 storedin association with a touched signature image 344 is displayed, as shownin FIG. 43. In the screen shown in FIG. 43, an “erase these” image 346permitting erase of guest_signature image file 452 corresponding totouched signature image 344 and associated guest_theme file 454 isfurther displayed.

When the user has input a plurality of pieces of image data (cameraimage or hand-drawn image) or audio data for one “theme”, such data maybe displayed in correspondence with the same signature image.

When “erase these” image 346 is touched with touch pen 27 etc., CPU 31determines that an erase target has been determined. Then, the processproceeds to step S396. In step S396, CPU 31 determines whether the imagedata (photograph or hand-drawn picture) or the audio data created in thepresent play of the association game has been selected or not. When theimage data (photograph or hand-drawn picture) or the audio data createdin the present play of the association game is selected (YES in stepS396), the process proceeds to step S385. Namely, the image data(photograph or hand-drawn picture) or the audio data generated in thepresent play of the association game is not stored but discarded.

On the other hand, when the image data (photograph or hand-drawnpicture) or the audio data created in the present play of theassociation game has not been selected (NO in step S396), the processproceeds to step S398. In step S398, CPU 31 overwrites selectedguest_theme file 454 with the image data (photograph or hand-drawnpicture) or the audio data created in the present play of theassociation game and overwrites corresponding guest_signature image file452 with the input signature image of the guest. Then, the processproceeds to step S385.

In step S385, CPU 31 determines, with regard to the same “theme”,whether already-stored owner_theme file 430 and/or guest_theme file 454is (are) present or not. When already-stored owner_theme file 430 and/orguest_theme file 454 is (are) present (YES in step S385), the processproceeds to step S387. On the other hand, when already-storedowner_theme file 430 and/or guest_theme file 454 is (are) not present(NO in step S385), the process proceeds to step S389.

In step S387, CPU 31 causes display of contents included in guest_themefile 454 created by the guest in the present play of the associationgame and contents in already-stored owner_theme file 430 and/orguest_theme file 454 in a comparable manner. Then, the processing forthe association game ends.

In step S389, CPU 31 has a screen inviting also the owner, in additionto the guest, to play the association game displayed. Then, theprocessing for the association game ends.

<Option>

Though not illustrated in the state transition diagram shown in FIG. 5,when “option” image 216 is touched with touch pen 27 etc. in the mainmenu for the owner shown in FIG. 8, additional functions are provided.Specifically, for example, in the application according to the presentembodiment, such functions as (1) commemorative photo creation, (2) agraph, (3) a theme album, (4) brain age comparison, (5) photographingagain of a head shot, (6) writing again of a signature, (7) checking ofhandedness, (8) erase of owner data, (9) erase of family and frienddata, and (10) erase all data can selectively be executed. Each offunctions (1) to (10) will be described hereinafter.

(1) A function for commemorative photo creation will be described later.

(2) When a function of a graph is selected, a graph of the owner's“brain age” as shown in FIG. 34 is displayed. Namely, independently ofexecution of the check game, a graph of the “brain age” is displayed.

(3) When a function of a theme album is selected, an image and the likeinput by the owner and/or the guest(s) for the selected “theme” aredisplayed in a list.

(4) When a function of brain age comparison is selected, a screen forcomparing “brain ages” between the owner and the guest as shown in FIG.35 is displayed. Namely, independently of execution of the check game, ascreen for comparing the “brain age” is displayed. In this case, displayis provided based on owner_brain age data 410 and guest_brain age file444 generated as the check game proceeded in the past.

(5) When a function of photographing again of a head shot is selected, ascreen for obtaining a face image as shown in FIGS. 20 to 25 isdisplayed, so that photographing again of a head shot or drawing againof a self-portrait by the owner user is allowed. The face image (headshot or self-portrait) obtained again is reflected in owner_setting file406.

(6) When a function of writing again of a signature is selected, ascreen for accepting input of a signature as shown in FIG. 26 isdisplayed, and setting again of a signature image by the owner user isallowed. Here, an already-registered signature of the owner user isdisplayed. The signature image set again is reflected in owner_settingfile 406.

(7) When a function of checking of handedness is selected, a screen forchecking handedness as shown in FIG. 11 is displayed, and setting againof handedness by the owner user is allowed. Setting of handednessselected again is reflected in owner_setting file 406.

(8) When a function for erase of owner data is selected, the entire dataor a part of the data on the owner is erased. When a part is to beerased, for example, data in accordance with user's selection from amongthe owner identification information (owner_face image file 402,owner_signature image file 404 and owner_setting file 406), the resultsof the training game (owner_training performance data 420), the resultsof the check game (owner_brain age data 410), and the results of theassociation game (owner_theme file 430) is selectively erased.

(9) When a function for erase of family and friend data is selected, forexample, a screen for selecting a guest to be erased as shown in FIG. 42is displayed. When any guest is selected, a screen requesting approvalby the user as shown in FIG. 43 is displayed and thereafter data on theguest of interest is selectively erased. It is noted that such afunction as erasing all data on the guest at once may be provided.

(10) When a function of erase of all data is selected, after approval bythe user, all data on the owner and the guest(s) stored in game device100 is erased.

<Commemorative Photo Function>

The function of commemorative photo creation described above refers to afunction to output a list of results obtained by execution of the checkgame and the association game described above. It is noted that the term“output” includes display of an image on a display screen, new creationof a file representing an image, transmission of image data to theoutside, and the like. In the description below, an example where a filerepresenting an image (for example, in a PEG format) is newly createdwill be shown as typical “output” processing.

FIG. 44 is a flowchart showing a procedure for processing thecommemorative photo function according to the embodiment of the presentinvention. FIGS. 45 and 46 are diagrams showing examples of outputscreated with the commemorative photo function according to theembodiment of the present invention. It is noted that the processingprocedure shown in FIG. 44 is performed when a “commemorative photocreation” image (not shown) displayed subsequent to selection of“option” image 216 in the main menu for the owner shown in FIG. 8 isselected.

Referring to FIG. 44, in step S400, CPU 31 determines for which of thecheck game and the association game creation of a commemorative photo isrequested. Namely, CPU 31 has an image inviting the user to makeselection as to for which of the check game and the association game acommemorative photo should be created displayed. When the creation of acommemorative photo for the check game is requested (“check game” instep S400), the process proceeds to step S410. On the other hand, whenthe creation of a commemorative photo for the association game isrequested (“association game” in step S400), the process proceeds tostep S420.

In step S410, CPU 31 determines whether file creation is permitted ornot. More specifically, CPU 31 has an image inviting the user to inputwhether to permit file creation or not displayed. When file creation ispermitted (YES in step S410), the process proceeds to step S412. On theother hand, when file creation is canceled (NO in step S410), theprocessing for the commemorative photo function ends.

In step S412, CPU 31 obtains stored brain age data of the owner and/orthe guest(s) and face image data associated with the brain age data. Insubsequent step S414, CPU 31 generates an image representing theobtained brain age data. In further subsequent step S416, CPU 31generates an output image by doing layout of the obtained image(s) eachrepresenting the brain age value and the face image data associatedtherewith. Thereafter, the process proceeds to step S430.

FIG. 45 shows an exemplary output image generated in step S414. In theoutput image shown in FIG. 45, not only the title, that is, list ofbrain ages, but also the brain age values of the owner and/or theguest(s) are displayed in a list, in correspondence with the respectivecorresponding face images. In the output image shown in FIG. 45, brainages for eight persons are displayed in a list.

In step S420, CPU 31 determines whether file creation is permitted ornot. More specifically, CPU 31 has an image inviting the user to inputwhether to permit file creation or not displayed. When file creation ispermitted (YES in step S420), the process proceeds to step S422. On theother hand, when file creation is canceled (NO in step S420), theprocessing for the commemorative photo function ends.

In step S422, CPU 31 determines for which “theme” a commemorative photoshould be created. More specifically, CPU 31 has images representingselectable “themes” displayed in a list as in FIG. 38 and specifies a“theme” corresponding to the image touched by the user. In subsequentstep S424, with regard to the selected “theme”, a stored theme file ofthe owner and/or the guest(s) is obtained and signature image dataassociated with the theme file is obtained. In subsequent step S426, CPU31 generates an output image by doing layout of the theme file and thesignature image data. Thereafter, the process proceeds to step S430.

FIG. 46 shows an exemplary output image generated in step S428. In theoutput image shown in FIG. 46, not only contents in the theme but alsocontents in the theme file of the owner and/or the guest(s) aredisplayed in a list, in correspondence with the respective correspondingsignature images. In the output image shown in FIG. 46, contents in thetheme files for six persons are displayed in a list.

In step S430, CPU 31 determines whether a capacity sufficient forstoring the output image can be secured in a memory in an outputdestination (for example, a capacity of data memory 34 for storage ormemory card 28) or not. When a capacity sufficient for storing theoutput image cannot be secured (NO in step S430), the process proceedsto step S432. On the other hand, when a capacity sufficient for storingthe output image can be secured (YES in step S430), the process proceedsto step S434.

In step S432, CPU 31 has an image for notification of shortage in acapacity in the output destination displayed. Then, the processing forthe commemorative photo function ends.

In step S434, CPU 31 causes the output destination to store the outputimage as a file. Then, the processing for the commemorative photofunction ends.

Although the present invention has been described and illustrated indetail, it is clearly understood that the same is by way of illustrationand example only and is not to be taken by way of limitation, the scopeof the present invention being interpreted by the terms of the appendedclaims.

1. A non-transitory computer-readable storage medium with an executableprogram stored thereon, wherein said program instructs a computerinteracting with an image pick-up portion and an input portion capableof detecting a coordinate on which an input operation was performed toperform a storage step of storing an input image in association withprescribed information, and a setting step of making setting as towhether a situation permits photographing by said image pick-up portion,and said storage step including the steps of when setting that thesituation permits photographing is made, storing a first image obtainedby photographing of a field by said image pick-up portion as said inputimage in association with said prescribed information, and when settingthat the situation does not permit photographing is made, acceptinguser's drawing input onto said input portion and causing a second imagein accordance with the drawing input to be stored as said input image inassociation with said prescribed information.
 2. The non-transitorycomputer-readable storage medium according to claim 1, wherein saidcomputer further interacts with a display portion, and said setting stepincludes the step of causing said display portion to display an imageinviting a user to make selection as to whether the situation permitsphotographing.
 3. The non-transitory computer-readable storage mediumaccording to claim 1, wherein said storage step includes the step ofstoring, for each of a plurality of pieces of prescribed information,any of said first image and said second image in association with eachpiece of the prescribed information.
 4. The non-transitorycomputer-readable storage medium according to claim 3, wherein saidprogram further instructs said computer to perform an output step ofoutputting in a list said first image or said second image associatedwith said plurality of pieces of prescribed information, incorrespondence with contents in the associated prescribed information.5. A non-transitory computer-readable storage medium with an executableprogram stored thereon, wherein said program instructs a computerinteracting with an image pick-up portion and an input portion capableof detecting a coordinate on which an input operation was performed toperform a storage step of storing a result of execution of a prescribedinteractive application and an identification image in association witheach other, an identification information input step of accepting, eachtime the prescribed interactive application is executed, input of saididentification image indicating a user who executed the interactiveapplication, and a setting step of making setting as to whether asituation permits photographing by said image pick-up portion, and saidstorage step including when setting that the situation permitsphotographing is made, storing a first image obtained by photographingof a field by said image pick-up portion as said identification image inassociation with said result of execution of said interactiveapplication, and when setting that the situation does not permitphotographing is made, accepting user's drawing input onto said inputportion and causing a second image in accordance with the drawing inputto be stored as said identification image in association with saidresult of execution of said interactive application.
 6. Thenon-transitory computer-readable storage medium according to claim 5,wherein said storage step further includes the step of storing a thirdimage obtained by photographing of the field by said image pick-upportion as said identification image in association with prescribedinformation associated with said second image after said second imagewas stored as said identification image in said storage step whensetting that the situation did not permit photographing was made in saidsetting step.
 7. An information processing device interacting with animage pick-up portion and an input portion capable of detecting acoordinate on which an input operation was performed, comprising: astorage portion for storing an input image in association withprescribed information; and a setting unit for making setting as towhether a situation permits photographing by said image pick-up portion,and said storage portion being configured to when setting that thesituation permits photographing is made, store a first image obtained byphotographing of a field by said image pick-up portion as said inputimage in association with said prescribed information, and when settingthat the situation does not permit photographing is made, accept user'sdrawing input onto said input portion and cause a second image inaccordance with the drawing input to be stored as said input image inassociation with said prescribed information.
 8. The informationprocessing device according to claim 7, wherein said image pick-upportion is arranged to include a face of a user in the field of saidimage pick-up portion while the user holds said computer.